copyleft hardware planet

May 24, 2015

Zedstar

Communicating XML concisely using Swift

Some background…

There are plenty of XML haters out there but this is a great quote:

XML is like violence: if it doesn’t solve your problem, you aren’t using enough of it.

Having spent quite a bit of time working with Lisp-like languages I am used to feeling syntax-fuelled hate. However, if what I send across the wire is not XML but something very concise I am not overly bothered about syntax. I will use XML, JSON, S-expressions, or whatever, as long as there are decent parsers. There have been numerous attempts to invent a new markup language or abstract syntax to represent the same kinds of data. When it comes to concisely transferring this data over a network you can adopt two approaches. You can send everything in one message or you can separate out the data you need to communicate from the structure and types but still allow the data to be reconstructed by the receiver. So you could take a chunk of markup and apply some text compression to it and send that binary across your network or you could send a minimal amount of data encoded into binary that relies on a schema or protocol to reconstruct it. The latter has the advantage of allowing the schema to be used multiple times on different sets of data as long as they conform to the schema. This means you can not only send less data but you can take advantage of fast encode/decode cycles by processing the schema once at startup and using that optimised version each time you encode and decode. This also provides the added benefit of allowing validation to take place on each encode and decode, something that text compression has no clue about. ASN.1 led the way in this approach. It was very powerful but complex which made tool support challenging. Google’s Protocol Buffers follows a similar approach but has a less abstract syntax to provide an easier way to map the data and types to programming languages. In the XML world there have been many attempts at compressing this verbose markup. In the end EXI emerged as the standard approach. However, I think the design is also flawed. In my opinion EXI suffers from the same problems as ASN.1, being overly complex to implement. That means you will struggle to find credible implementations outside of enterprise computing. I also don’t think it makes sense to try and invent a general serialisation approach to XML because there are too many caveats. At some point you will give in and employ text compression instead. So when I decided to make an XML serialisation tool I wanted to recognise these limitations. Packedobjects was based on ASN.1 but represented in a subset of XML Schema. It has a limited set of data types that are enough to write network protocols. It deliberately restricted XML Schema to control things like the order of data and the way data repeated. For example, I don’t think it makes much sense to support a set data type when machines are pretty good at generating things in the same order each time.

Going mobile…

If you are working on restricted platforms such as mobile or embedded devices, in the end it is all about tool support. This is where I believe XML does well. If you want to support parsing a schema language efficiently you probably have few options. Libxml2 does a great job of this and it does it quickly. What’s more, this parser is everywhere. For example, it can be in your pocket right now if you own an iPhone. I decided to see how Packedobjects would perform on iOS if I wrapped the current API in a more high-level interface that worked with strings rather than expose the more lower-level Libxml2 doc type API. The porting process was fairly quick and painless. I built an example program that can take all the XML files in the Packedobjects repository and ran them to get performance metrics.

Result of decoding 1000 encodes/decodes
The screenshots show the results running on a 5th gen iPod. This example is available to try out here. There is quite a big discrepancy between encoding and decoding speed performance but overall I am pleased at how the tool performs on the devices I tried. I will be adding support for 64bit encoding and decoding soon to see what impact this has on an iPhone 6.

Size matters…

One thing I avoided talking about in this post until now is the key metric of encoding size. Rather than believe what I say you need to pick your data set and try for yourself. For the type of data I work with, Packedobjects outperforms other approaches I tried. I would classify this data as highly structured and not dominated by string data types. So the kind of data that might originate from the Internet Of Things (IoT), sensor networks, network management and so on.

by john at May 24, 2015 01:30 PM

Andrew Zonenberg, Silicon Exposed

Graduating, TDR prototype, lab move, and a conference talk

So, it's been a busy couple of months and I haven't had time to post anything. Here's a few quick updates:

I successfully defended my Ph.D thesis few weeks ago and will be graduating next weekend. You can download the thesis and browse the code if you're so inclined. I plan to continue developing the project in my spare time and using it as the basis for future embedded gadgets so expect more posts on it over the coming months.

The TDR board came in and I assembled the first prototype. It had a few bugs (which I'll detail in a future post) but after reworking them all of the major subsystems seem functional and I'm working on the firmware. Expect another post over the summer once I've made more progress.
TDR prototype during bring-up.
This was my improvised jig for holding probes on small test points.
Now that I'm done with school I'm moving across the country in a week to start work at my new job. My lab is currently living in 125 cardboard boxes weighing just shy of 1900 pounds. (This doesn't count my desktop computer and monitors, test equipment, microscope bench, or the servers and rack as they're all still in use and being packed up over the next few days.) The lab will be totally down for 1-2 months.

The current state of my lab
Finally, I will be speaking on CPLD reverse engineering at REcon this June. The topic of the talk is the XC2C32A, which my regular readers may remember from a previous post. I'll be describing the reverse engineering process, how far I got, and showcasing bitstreams generated by my toolchain running on actual silicon. If any you are going, by all means introduce yourself :)

by Andrew Zonenberg (noreply@blogger.com) at May 24, 2015 12:42 AM

May 15, 2015

Free Electrons

ELC 2015 videos available

The videos from the last Embedded Linux Conference that took place late March in San Jose, California, are now available on Youtube! This represents a lot of interesting and useful content about embedded Linux topics.

You’ll find below the videos of the three talks given by Free Electrons engineers at this Embedded Linux Conference.

An Overview of the kernel DMAEngine subsystem, Maxime Ripard

MLC/TLC NAND Support: Challenges for MTD/NAND Subsystem, Boris Brezillon

The Device Tree as a Stable ABI: A Fairy Tale?, Thomas Petazzoni

by Thomas Petazzoni at May 15, 2015 07:19 AM

May 12, 2015

Michele's GNSS blog

A modern GNSS front-end

Earlier this year I had the occasion and privilege to be trying out a new front-end produced by NTLab, the NT1036. I thought it would be interesting to share this with the GNSS crowd.
The kit arrived composed by two separate boards: a control board and the actual chip evaluation board, as well as a CD with the software and detailed data-sheet. The controller board connects seamlessly to the evaluation one by means of a single flat cable with RJ12 ends. Although the suggested supply voltage is 3.0V pm5%, it was very convenient to use the same cable to power the board with 3.3V. Also, having a single common supply avoids currents on the control lines. In the end the chip worked fine in this configuration so I assume it was a safe choice to take.
The chip has many unique characteristics that make it suitable for a modern GNSS receiver. The ones of greatest interest to me are the following:
  • Four independent input channels
  • Two wideband VCO banks, on high and low RNSS bands, which can be routed with great flexibility amongst the four mixers, in particular allowing:
    • GPS/Glonass L1+L2 or L1+L5
    • GPS/Beidou L1+L2 or L1+L5
    • All 4 channels on either L1 or L2/L5
  • 3.0V supply voltage and low power dissipation (ideal for USB-powered devices)
  • Analog or digital output options for IF (real-only, which I like best) and clock lines.
  • Small, easy to assemble package
Obviously, the killer applications for this kind of chip are well contained antenna arrays and multi-frequency multi-constellation hardware and software receivers.
Having a lot of testing equipment at hand one could really crack a nut like this one. However, with limited hardware at hand I decided to use my SdrNav40 board and slightly modify its firmware so to ignore the 4 on-board RF channels and capture instead the evaluation kit outputs and clock.
Figure 1: Test setup, with 4 way power splitter and SdrNav40 powering the antenna.
Figure 2: Closeup of the test setup
Two tests were particularly useful for me: GPS/Glonass L1+L2 and four channels on L1. The first should lift any doubt on the potential fields of application of the chip. The second should solve my curiosity on phase behaviour of common LO (Local Oscillator) MI (Multiple-Input) front-ends.
The GUI to control the configuration of the NT1036 is incredibly rich and professional: low hanging fruit for a curious engineer.
Figure 3: NT1036 configuration tool: general settings tab, where the synthesizers can be programmed
Figure 4: NT1036 configuration tool: channels 1 and 2 tab
Figure 5: NT1036 configuration tool: main chip blocks tab
For GPS/Glonass reception the tuner offers a default configuration with the two VCO banks tuning in the middle between GPS L1 and Glonass G1 (and similarly for L2/G2), thus having GPS in high-side mixing and Glonass in low-side mixing. Configurable IF filter banks select one or the other. The distance between the centre frequencies (being about 26 MHz on 20 MHz for high and low RNSS respectively) suggests a L1 plan in which a FS of about 52 MHz puts both carriers around FS/4 for ease of down-conversion. Setting FS to 53MHz (derived from an integer PLL) allows achieving GPS L1 on 14.58 MHz. Plots that everyone likes follow.
Figure 6: PSD of samples acquired in high-injection mode on L1 at about 50Msps
Figure 7: Histogram and time series of the signal acquired with NT1036 (sign and magnitude output)
Figure 8: Results of GPS satellites acquisition.

I have in mind to continue my tests on the chip, subject to time which is always very little!
Till next time...

by noreply@blogger.com (Michele Bavaro) at May 12, 2015 08:43 PM

May 10, 2015

Elphel

NC393 Development progress: Multichannel memory controller for the multi-sensor camera

Development of the NC393 camera has just passed an important milestone  – we completed HDL code that constitutes the core of this new camera, tested most of the Zynq-specific features that were not available in the older Spartan-3 FPGA used in our current NC353 devices. Next development phase  will involve porting some of the existing code that deals with sensor interfacing, gamma correction, histograms, color conversion and JPEG/JP4 compression – code that was tested in the thousands of cameras and many billions of processed images, including the applications listed in Wikipedia. New camera is designed primarily for the multisensor applications – up to four connected directly to the system board and more through the multiplexers as we currently do in Eyesis4π cameras. It is the memory controller that had to be redesigned completely, the sensor and compressor channels can reuse most of the existing code and just have 4 instances of the same modules instead of a single one. Starting early this year I’ve got an opportunity to put aside other projects and work full time on the new camera code.

FPGA features different from the previous Elphel cameras

The new features tested include I/O elements needed to implement DDR3 interface (described in the earlier posts) and communication between the ARM cores (PS – processing system) and the FPGA (PL – programmable logic). Zynq has multiple channels of communication based on AXI standards, 2 of the interface types are used in the current design:
SAXI_GP0 – general purpose memory-mapped interface controlled by the processors, convenient to write data to various registers inside the FPGA fabric that determine the operation of the device. Read channel of the interface allows CPU to get status information back from the PL.  This interface is 32-bit wide and it is not intended for high bandwidth applications.
AXI_HP0 – high speed channel allowing 64-bit wide transfers between the system memory and the FPGA logic. Zynq offers 4 of such channels, current design uses one to implement a two-directional “bridge” between the system memory and the dedicated DDR3 device connected to the FPGA and used as an image/video buffer. Two of the remaining channels will be used to transfer compressed images to the system memory (to stream out and/or record to HDD/SSD), and one for SATA interface.
Other AXI channels that are not yet used in NC393 code include ACP (Accelerator Coherency Port) that has the same bandwidth as the AXI_HP, but “sees” the memory the same way as the processors do (through the same cache levels), this port is intended as its name suggests for the “accelerators” – programmed logic tightly coupled with the CPU, where the latency is critical but the amount of data transferred is relatively small, so it will not disturb the normal cache usage by the processors.
Implementation of the HDL code that interacts with these AXI ports took more time than it should, partly because the Zynq manufacturer does not provide HDL code for simulation, only proprietary encrypted modules are available – modules that are useless for our preferred Free Software tools. When I tried to simulate AXI interfaces I only got the output from the following statement:
$display("Warning on instance %m : The Zynq-7000 All Programmable SoC does not have a simulation model. Behavioral simulation of Zynq-7000 (e.g. Zynq PS7 block) is not supported in any simulator. Please use the AXI BFM simulation model to verify the AXI transactions.");
We had to implement both the synthesizable HDL modules for our product and the simulation code for SAXI_GP and AXI_HP missing from the software distribution. This code definitely has limitations compared to the proprietary encrypted one – we implemented only the features needed in our design (for AXI_HP it does not provide 32-bit bus functionality).  Nevertheless  it seems to work for our application and is now available under GNU GPLv3 license for others to use as a part of x393 project at GiHub.

Custom memory controller

External memory controller is a rather intimate part of the system design and I do not believe it is possible to create an efficient one-size-fits-all code. Yes, Xilinx offers MIG IP that can be inserted into your custom design, but we need more control over what is going on inside it, the earlier post “DDR3 Memory Interface on Xilinx Zynq SOC – Free Software Compatible” describes the physical layer (PHY) of the implementation. Dynamic RAM devices impose multiple access  restrictions, and the general purpose memory controller essentially tries to hide these details from the processes that use the memory, while keeping the data rate as close as possible to the theoretically available (clock frequency multiplied by bus width multiplied by two for DDR devices).
Some of the main specifics of the dynamic RAM devises are:

  • Memory is page-oriented, access within the same page is fast, but opening/closing pages (“activate” and “precharge” terms are used in the device manuals) is slow
  • Data transfer happens in multi-word “bursts”, DDR3 devices have normal bursts of 8 words (width depends on the memory organization) and short ones of 4 bursts, but short bursts use the same time as the 8-long ones so they do not offer advantage when transferring large amount of data. For our application we can consider memory device to be 128-bit (8*16 bits) wide
  • Memory array is divided into  “banks” (DDR3 has 8 of them), and transfers to/from one bank can take place with simultaneous activation/precharging of other one(s) as these operations do not use the data bus.

These features provide a clue – how to get a high average bandwidth. Basically there are 2 strategies:

  • Consolidate multiple accesses to the same page. In the simplest form (common for the camera designs) write consecutive memory locations (like fill memory with the scan-line data from the sensor). With 16-bit wide memory it is possible to transfer up to 2048 bytes at the full memory bandwidth with just one “activate” in the beginning and one “precharge” (or auto-precharge) in the end.
  • Design the memory addressing in such a way, that translation of the linear address to physical bank, page number (“row address” in DRAM terminology) and in-page address (“column address”)  makes it likely to simultaneously operate multiple banks.

While the first clue is easy to follow, the second one is not. Depending on the particular clock speed/timing parameters, you may need 3-5 banks to interleave to provide full data bandwidth utilization, something rather difficult to achieve for random data access without making special assumptions about the nature of the application data.
Camera deals mostly with the 2-d data arrays and majority of scenarios use either sequential (scan-line ordered) access or depend on 2-d locality of the pixels (compression, de-warping, correlation, filtering, and more). This mode can use tiled access and read/write small rectangular pixel areas as atomic operations.  Contrary to the general processing memory, latency is not usually critical for the image memory,  access patterns are predictable and can be pre-optimized in advance, not at the run time during memory access.
This allows to optimize a custom memory controller dedicated to image acquisition, processing and compression, and in our case support multiple image sensors operating in parallel. Particular application may include optical image-guided UAVs and other robotic devices.

Memory mapping and access types

Mapping of the 2-d imaging objects to the DRAM memory addresses targets both sequential and tiled accesses. Each image scan line uses a single bank address (0..7) and increasing column addresses (2048 bytes or 128 bursts), then row addresses. Each group of 8 lines share the same row/column addresses and have individual banks for each row as shown on Fig.1.

Figure 1. Memory layout for 2-d image objects

Figure 1. Memory layout for 2-d image objects

Atomic memory accesses are currently limited to ¼ of the 4KB BRAM memory blocks available in Xilinx Zynq FPGA part, that makes 64 bursts or ½ of the memory page. Crossing page boundary during sequential access requires precharge and activation of the different memory pages in the same bank, so while the code can split accesses automatically it is beneficial to align the full frame width to the multiple of the 64 bursts (1024 8-bit or 512 of 16-bit pixels).

Scanline frame access

Memory controller provides application modules with a scanline windowed access to the image frames defined by the memory start address and the full (possibly padded) frame width, measured in 16-byte bursts. Access window is defined by conventional X0, Y0, width (in bursts) and height (in lines/pixels).

Figure 2 Access window in scanline mode

Figure 2 Access window in scanline mode

Scanline access module splits the requested window into a sequence of up to 64-burst data transfers, generates “page ready”, “frame ready” signals to application module, accepts “frame start”, “next page” signals. It also supports inter-channel synchronization by providing “next line number” output and “suspend” input. External module can compare last line number acquired from the sensor input channel and suspend compressor/image processing module, providing low-latency video.

Tiled frame access

Many image processing and compression algorithms consume or generate 2-d blocks(tiles) of data. Some applications require overlapping tiles, including regular JPEG compression of color images. While compression algorithm itself uses non-overlapping 8×8 pixel blocks (16×16 macroblocks for 4:2:0 mode), extra pixels around the blocks are needed for Bayer-to-YCbCr conversion that is convenient to implement right in front of the compressor where the data is already available in 2d format, not in scanline order as it comes out of the sensor.

Figure 3 Access window in tiled mode

Figure 3 Access window in tiled mode

Tile overlap is needed both horizontally and vertically, but horizontal overlap is easy to implement in the application module just by using already buffered (in FPGA BlockRAM) data from the previous tile, while vertical overlap would need buffering the whole width of the sensor that would be not scalable for high resolution sensors and would require extra BlockRAM modules in the fabric. This is why the memory controller module provides only vertical tile overlap, accepting 3 byte-wide (width is limited by the total “area” of 64 bursts in a tile)  parameters – tile width, tile height and tile step in addition to X0, Y0, window width and window height.

Tile internal structure

Memory controller provides support for the 2 types of tiles. First type (Tile16) maps data to the sequence of bursts as vertical columns, each burst representing horizontal row of 16 (8-bpp mode) or 8 (16bpp mode) pixels.

Figure 4a: Tile16 - tile with 1 burst-wide columns

Figure 4a: Tile16 – tile with 1 burst-wide columns

Figure 4b: Tile32 - tile with 2 burst-wide columns

Figure 4b: Tile32 – tile with 2 burst-wide columns

Columns are traversed up to down, then left to write as shown on Fig. 4a. Due to memory timing restrictions this mode allows only some values for the tile height (0,6 and 7 modulo 8). Tile32 allows more variants for the tile height as there is more clock cycles between re-opening different page for the same bank, it can be (0,3,4,5,6,7 modulo 8). All tiles with the height of less than or equal to 8 are valid as it is possible to keep all banks open between columns of a tile, all heights are valid for the single-column tiles too. Single-column tile32 of maximal size (64 bursts) corresponds to a square area of 32×32 pixels in 8 bits per pixel mode.

NC393 HDL code and the memory controller implementation

Elphel camera code is built around the 16-channel DDR3 memory controller and at this stage the only modules that are not part of this controller are command and status distribution networks, system memory to external memory bridge over AXI_HP and temporary test modules to test controller functionality.

Figure 5. Memory controller block diagram

Figure 5. Memory controller block diagram

Command and status networks

Command distribution tree is designed to write data to various memory-mapped registers distributed over the whole design. All these registers are write-only (readback is optionally provided by a separate Block RAM-based module), so data paths can accommodate any number of register slices if needed to meet timing. This bus is a light-weight to minimize required routing resources of the FPGA, it requires only 9 data signals (9 address/data and a strobe) and can deliver 0 to 32 bits of data (configured by parameters at the destination module) sent over 1 to 6 clock cycles. Command distribution tree accepts commands from the software over the MAXI_GP0 or from a PL sequencer driven by the frame synchronization signals from the sensors – it will be ported from the current NC353 camera HDL code.
Status receive tree supplements the command tree and provides processing system with a feedback data from the distributed over the FPGA fabric modules. It includes a 256×32 register file available for PS read access with zero latency and a unidirectional tree of light-weight (10 signals) network that also includes multiplexers and status transmitters. Multiplexers route the messages (up to 6 clock cycles long depending on a payload) to the terminating register file. Status transmitters (controlled through the command distribution network) provide means to synchronize responses to the PS requests using 6-bit IDs, they send up to 26-bit status information either in response to a command or automatically when the input data changes.

Memory interface

Memory interface is forked from an earlier eddr3 project (there are some important bug fixes). In addition to the physical layer components it includes sequencer that generates address and control signals for memory device access following the program data prepared in advance. This sequence programs come from one of the two sources – PS Sequence Memory written under the software control and PL Sequence Memory filled in by one one of the Sequence encoders just before (during previous memory transaction) the execution. Both memories are made of 4KB Block RAM modules. PS sequences are used for memory refresh access instructions, memory initialization and calibration, any other pre-programmed memory operations that need to be executed following specific timing.
Memory interface is configurable with Verilog `define macros and can interface up to 16 concurrent channels, each being read-only, write-only or bidirectional. Each channel is supposed to have a 4KB block RAM buffer (or two of them for bidirectional channels) configured in SDP (simple dual port) mode with 64-bit wide input (for memory read) or 64-bit output (for memory write). Memory interface also provides channels with clock and control signals for the memory side of the buffers, other side of these dual-port buffers is under channel logic control, it may be clocked by a different source. Two layers of registers may be inserted in both input (16:1) multiplexer path and output distribution of the 64-bit wide data buses that may need routing to different parts of the device.
Channel buffers are based on 4KB block RAM modules, each split into 4 of 1KB pages, making them suitable for up to 64 of 16-byte bursts transfers. Of the four pages one (in some overlapping tiles applications – two) is in use by the channel logic (being consumed or generated), another is used by the transfer to/from the DRAM memory, and the remaining ones provide needed buffering when memory is in use by the other channels.

Channel arbiter

16-channel arbiter accepts two levels of urgency (“want” and “need” signals) from the channel controllers. In most cases memory read channels generate “need” if there is at least one empty buffer page and the channel will need it later (not the last pages in a frame), “need” is generated when the channel is consuming the last available page. Similarly for the memory write channels – “want” is generated when there is at least one completed page, “need” – when there is no empty pages left. Channels that can wait for the data can skip raising the “need” signal leaving more resources to other channels that are tied to constant data rate data (such as inputs from the sensors).
In addition to the two levels of urgency (channels with ”need” requests are served before “want” ones compete) arbiter provides channel priorities. Each channel has associated counter that increments at each event (new request or request grant), taking care of the simultaneous requests by static priority by channel number. The channel having highest counter value wins, receives “grant” signal and that channel counter is reset to the specified channel priority value, so priority 0 makes that channel to wait maximal time.

Figure 6. Memory access arbitration and timing

Figure 6. Memory access arbitration and timing

Sequence generation takes less time than the actual memory access, and channel arbitration happens when the previous sequence data is sent for execution. Fig. 6 shows that channel 2 sequence is started to be transferred to the PL Sequence Memory as soon as the memory interface starts to execute sequence for channel 1.
There is an additional arbitration just before starting to execute a sequence – if refresh module (it does not need to transfer sequence data as it is already in the PS Sequence Memory) generates “want” or “need” request, it competes against the already granted channel that has the sequence ready to be executed – Fig. 6 shows how REFR sequence passes the CHN1 that is ready to be executed. The sequence FIFO in PL Sequence Memory allows only one sequence to be buffered. This limit is imposed to reduce waiting for service of the urgent (“need”) requests while not using a more complicated mechanism that would allow such requests to pass other channel non-urgent (“want”) requests in the sequence memory FIFO. It is still a possibility for the future improvements to allow efficient execution of significantly different size memory transfers.

Sequence Encoders

Sequence encoders are shared between the channels – the channel that wins the arbitration is granted to generate a memory access sequence. Currently there are 6 of such modules that generated scanline read, tile16 and tile32 (see Fig. 4a-b) and similar for memory writes. These modules accept address and size parameters from the window access controllers and use HDL-encoded templates to generate control sequence for the next memory access operation.

Channel window access controllers

Window access controllers implement access to selected rectangular areas inside the image frame. There are two types currently available – scanline access (Fig. 2) and tiled access (Fig.3). Distinction between read and write modes, and between tile16 and tile32 modes are passed as run-time parameters. They are used later to select the specific sequence encoder each time the request is granted by the arbiter. These modules require individual instances for each channel that uses them as they have to keep track of the related channel buffer, tile location and other module state variables.
Additional controllers will be developed for other types of accesses when needed by the image processing algorithms that may need other types of memory accesses. Example application may be a distortion correction procedure where either input or output use tiles that are not defined by a regular grid).

Memory access channels

Channel 0 is designed for programmable access to the memory. It uses PS Sequence Memory written through MAXI_GP0 under the software control. It has both read and write buffers for operations that involve data transfer, it is used for memory initialization and calibration/training, it can also be used to test other access sequences without re-generation of the bitstream.
Channel 1 implements a fast bi-directional bridge between the system memory and the dedicated image memory. On the system side it uses AXI_HP0 port in 64-bit mode, on the image memory side it implements a scanline window access It is possible to either fill the selected window in the image memory with the consecutive data from the system memory, or read image memory window  to a linear array in the system memory.
Channels 2-5 will be used to record data from the four sensor ports, currently one channel is connected to 2 buffers connected to the SAXI_GP0 interface for testing scanline windowed memory access.
Channels 6-9 will be used in tile32 mode to read 2d data for image compression. Temporary implementation uses 2 channels connected to SAXI_GP0 read/write for testing purposes.
Remaining six channels may be used for application-specific image processing.

Software tools used

The list of the tools used for this project is the same as listed for the earlier eddr3 project. The only difference is that now it is Eclipse Luna instead of Kepler, and some bugs in VDT plugin are fixed – bugs that revealed themselves while this plugin was being used with gradually growing code base.
The x393 project code itself is available under GNU GPLv3 Free Software license, does not depend on any undocumented or encrypted “IP” modules and can be simulated with the Free Software tools. Project configuration files allow importing it to Eclipse IDE when VDT plugin is installed.

by andrey at May 10, 2015 03:15 AM

May 06, 2015

Free Electrons

Free Electrons contributes U-Boot support for SECO i.MX6 uQ7 board

SECO i.MX6 uQ7 SOMAmongst the multiple customer projects we are currently working on that rely on i.MX6 based platforms, one of them is using the SECO i.MX6 µQ7 System on Module as its heart. Unfortunately, the SECO Linux BSP relies on old U-Boot and Linux kernel releases, which we didn’t want to use for this project.

Therefore, Free Electrons engineer Boris Brezillon has ported the mainline U-Boot bootloader on this platform, and contributed the corresponding patches. These patches have been merged, and the support for this platform is now part of the 2015.04 U-Boot release. To build it, simply use the secomx6quq7_defconfig configuration.

The work behind these patches was funded by ECA Group.

by Thomas Petazzoni at May 06, 2015 07:45 AM

May 05, 2015

Free Electrons

Free Electrons engineer Alexandre Belloni co-maintainer of the Linux RTC subsystem

SparkFun Real Time Clock ModuleThe Linux RTC subsystem supports the Real Time Clock drivers for a large number of platforms and I2C or SPI based Real Time Clocks: it contains about 140 different device drivers, plus the RTC core itself. The current maintainer, Alessandro Zummo, had unfortunately very little time to address all the patches that were sent, and many of them where usually handled by Andrew Morton, acting as a fallback for various parts of the kernel that are not enough actively maintained.

To address this lack of maintainer time, Free Electrons engineer Alexandre Belloni recently became a co-maintainer of the RTC subsystem, as can be seen in this patch to the MAINTAINERS file. Alexandre has already started his work by cleaning up the patchwork instance listing all the pending RTC patches, reducing the number of pending patches from 2843 to 436, actively applying new patches being posted, and reviving old patches that never got any attention.

Up to the 4.1 release included, RTC patches will flow to Linus Torvalds through Andrew Morton, but starting from Linux 4.2, Alexandre will start sending his pull requests directly to Linus.

by Thomas Petazzoni at May 05, 2015 12:28 PM

Video Circuits

London Alternative Photography Collective Talk on Optical Sound

I will be doing a talk later today about optical sound and the history of photography of sound, Sally Golding will also be showing some of her work!
http://lapc.format.com/next-meeting 
http://www.facebook.com/events/497347793749239/















Photo from Seeing Sound by Winston E.Kock

by Chris (noreply@blogger.com) at May 05, 2015 08:31 AM

April 30, 2015

Video Circuits

Psyché Tropes + Video Circuits

Here are a few images from the night we did a while back and some video shot by Video Hack Space! thanks Fabrizio!










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

April 28, 2015

Bunnie Studios

Name that Ware April 2015

The Ware for April 2015 is shown below.

Have fun!

by bunnie at April 28, 2015 11:36 AM

Winner, Name that Ware March 2015

The Ware for March 2015 is a PC AT Single T4 4 Meg Transputer board assembly. Jim is the winner, congrats! Email me to claim your prize.

by bunnie at April 28, 2015 11:36 AM

April 25, 2015

Elphel

FPGA to DDR3 memory interface: step-by-step timing calibration and set up

Working with the DDR3 Memory interface I was not able to avoid the temptation to investigate more the very useful feature of the modern FPGA devices – individually programmed input/output delay elements on all (or at least many) of its pins. This is needed to both prepare to increase the memory clock frequency and to be able to individually adjust the timing on other pads, such as the sensor ports, especially when switching from the parallel to high speed serial interface of the modern image sensors.

Xilinx Zynq device we are using has both input and output delays on all low-voltage pins used for the memory interface in the camera, but only input ones on the higher voltage range I/O banks. Luckily enough image sensors connected to these banks need just that – data rate to the sensors is much lower than the rate of the data they generate and send to the FPGA.

Adjusting memory timing with Python code

Adjustment of the optimal pin delays for the memory interface can be done in several ways, and many applications require that it should be either all implemented in hardware or use very limited CPU resources – that is the case when the memory to be set up is the main system memory and so CPU can not use it. On the other hand when the memory is connected to the FPGA part of the system that is already running with full software capabilities it is possible to use more elaborate algorithms.

I call it for myself “the Apple ][ principle” - do not use extra hardware for what can be done in software. In the case of the delay calibration for the memory interface it should be possible to use a reasonable model of the delay elements, perform measurements and calculate the parameters of such model, and finally calculate the optimal settings for each programmable component. Performing full measurements and performing parameter fitting can be a computationally intensive procedure (current Python implementation runs 10 minutes) but calculating the optimal settings from the parameters is very simple and fast. It is also reasonable to expect that individual parameters have simple dependence on the temperature so it will be easy to adjust parameters to the varying system temperature. Another benefit of such approach that it can use delay elements with even non-monotonic performance (that is sometimes in case when using FINEDELAY elements) and finally – the internal parameters of the delay elements do not depend on the clock frequency, so parameters can be measured at lower clock frequency and then settings can be re-calculated for the higher one. Adjusting timing parameters at the target frequency can be more difficult as there can be much smaller windows of the combination of the parameters that allow memory device to operate, it may be not possible to probe marginal values of some delays (to calculate the optimal center value) as it may violate other timing parameters.

The procedure described below can be used to measure the delay parameters of the memory interface and find the optimal combinations of the settings requiring no manual adjustments of the initial values. The software is written in Python and is a part of the Elphel GitHub repository x393 as x393/py393 PyDev project.

The Python code includes a module that can parse Verilog header files with parameter definitions so all the changes in the HDL code are automatically applied to the Python program, running the program on the target hardware generates updated values of the delay settings as a Verilog file, so these measured values can be used in simulation. This program is of course designed to run on the target platform, but most of the processing can be tested on a host computer - the project repository contains a set of measured data as a Python pickle file that can be loaded in the program with a command "load_mcntrl dbg/x393_mcntrl.pickle". Program can run automatically using the command file provided through the arguments, it also supports interactive mode. Most of the functions defined in the program modules are exposed to the program CLI, so it is possible to launch them, get basic usage help. Same is true for the Verilog parameters and macro defines - they are available for searching and it is possible to view their values.

Delay elements in the memory interface

Fig.1 Memory interface diagram showing signal paths and delays

Fig.1 Memory interface diagram showing signal paths and delays

There are total 61 programmable delays and a programmable phase shifter as a part of the clock management circuitry. Of these delays 57 are currently controlled – data mask signals are not used in this application (when needed they can be adjusted by the similar procedure as DQ output delays), ODT signal has more relaxed timing and the CKE (clock enable) is not combined with the other signals. There are 3 clock signals generated by the same clock management module with statically programmed delays: clk (same frequency as the memory clock), clk_div (half memory frequency) and mclk – also half frequency, but with 90 degree phase shift with respect to clk_div, it is driving the memory controller logic. Full list of the clock signals and their description is provided in the project.

Variable phase shifter (with the current 400 Mhz memory clock it has 112 steps per full clock period) is essentially providing variable phase clock driving the memory device, but to avoid dependence on the memory internal PLL circuitry, memory is driven by the non-adjusted clock, and programmed phase shift is applied to all other clock signals instead.

Address/control signals and data to be written to the memory device originate in the registers and Block RAM of the controller running at mclk global clock, then they go through serializers (OSERDESE2 for synthesis, OSERDESE1 for simulation to avoid undisclosed code modules). Serializers use two clocks and in this design the slower clk_div is ¾ of the mclk period later than mclk itself to guarantee positive setup time when crossing the clock boundary. Serializers for data, data mask and DQS strobes operate in DDR mode, while the ones for address and command signals use single data rate mode. Each of this signals pass through individual 32-tap delay with nominal 78 ps/step, followed by a a 5-tap fine delay element (ODELAYE2_FINEDELAY) and then go to the external memory device.

On the way back the data read from the memory and the read strobes (one per each data byte) pass through IDELAYE2_FINEDELAY elements and then strobes pass through BUFIO clock buffers that drive input clock ports of the deserializers ( ISERDESE2 for synthesis, ISERDESE1 for simulation), while the same (as used for the output serializers) clk and clk_div drive the system-synchronous ports. When crossing clock boundary to the mclk registers that receive data from the deserializers use the falling edge of mclk and there is again ¾ of mclk period to guarantee positive setup time.

The delay measurement procedure involves varying the delay that has uniform phase shift step (1/112 memory clock period) and adjustment of the variable “analog” pin delays that have some uncertainty: constant shift, scale (delay per step) and non-linearity. The measurement steps that require writing data to the memory and reading it back, and so depending on the periodic memory refresh, the automatic refresh is temporarily turned off when the clock phase and command delays are modified.

Measuring delays in the signal paths and setting memory interface timing

Step 1 : Finding valid command/address delays for each clock phase setting

The first thing to do to be able to operate the memory is to find the address/command line delay that is safe to use with each clock phase and/or find what values of the phase shift are valid. The address and command signals use single data rate (sampled at the leading edge of the clock by the memory device) so it is easier to satisfy the setup/hold requirements than for the data. DDR3 devices provide a special “write levelling” mode of operation that requires only clock, address/command lines and DQS output strobes providing result on the data bus. At this stage timing of the read data is not critical as the data data stay the same for the same DQS timing, and it is either 0×00 or 0×01 in each of the data bytes.

It is possible to try reading data in this mode (reading multiple data words and discarding groups of first and last one no remove dependence of read data timing) and if the result is neither 0×00 nor 0×01 then reset the memory, change the command delay (or phase) by say ¼ of the clock period, and start over again. If the result matches the write levelling pattern it is possible to find the marginal value value of the address delay by varying delay of address bit 7 when writing the Mode Register 1 (MR1) – this bit sets the write levelling mode, if it was 0 then the data bus will remain in high impedance state.

Fig.2 Finding the command/address lines delay for each clock phase

Fig.2 Finding the command/address lines delay for each clock phase

Memory controller drives address lines in “lazy” mode leaving them unchanged when they are not needed (during inactive NOP commands) so it is easier to check if A[7] low → high transition happens too late. Additionally the tested write levelling command have to be preceded by some other command with A[7] at low level.

Figure 2 shows the process of scanning over phases and finding the longest delay on A[7] line that still turns on the write levelling mode (shown with red diamonds). Command line delays are kept at zero until at phase 82 the delay on A[7] line becomes smaller than a preset limit (command lines are almost too late themselves), at this phase the command line delay is increased so the command is recognized in the next clock cycle and so the marginal value of A[7] is also increased by the full clock period. With the current settings the full delay range is almost exactly equal to the clock period, this will not be the case at higher memory clock rates (delays will cover more than a period) or increasing the delay calibration clock rate from 200 MHz to 300 MHz (delays will cover les than a period). On the Figure 2 there is a small gap (to phase=86) when the marginal delay for A[7] can not be measured as it would exceed the maximal delay value available in OSERDESE2 element.

Yellow triangles show the optimal values for the A[7] delay calculated by applying linear interpolation to the marginal values and shifting the result horizontally by ½ of the clock period (56 phase steps).

At this preliminary stage optimal command/address delays are assumed to be the same as for the A[7] – they are connected to the same I/O bank. Later it will be possible to optimize each signal delay individually, when switching to the higher frequency the relative differences between lines can be assumed the be the same and can be applied accordingly.

During the next stages of the delay measurement the command and address lines delay values are all set whenever the clock phase is changed.

Step 2: Measuring individual delays for command (RAS,CAS,WE) lines

Fig.3 Command lines delays measurement

Fig.3 Command lines delays measurement

When the approximate value for the optimal delay for the address/command lines is known it is possible to individually calibrate delay for the command lines. The mode register set command involves high (inactive) to low (active) state on all 3 of them, so it is possible to probe turning on the write levelling mode when 2 of the the 3 command lines (and all the bank and address lines) are set with the optimal values, while the delay on the remaining command line is varied. Sometimes this procedure leads to the memory entering undefined/non-operational state (write levelling pattern is not detected even after restoring known-good delay values), when such condition is detected, the program resets and re-initializes the memory device.

To increase the range of the usable phases the other command/address lines are kept at delay=0 while there still is a safe margin of the setup time with respect to memory clock (from phase = 32 to 60 on Fig. 3)

Step 3: Write levelling – finding the optimal DQS output delays for clock phase

Fig.4 DQS output delay measurement with write levelling mode

Fig.4 DQS output delay measurement with write levelling mode

This special mode of DDR3 devices operation is intended to adjust the DQS signal generated by the controller to the clock as seen by the memory device, it measures clock value at the leading edge of the DQS signals and replies with either 0×00 (clock was low) or 0×01 (clock was high) on each data byte of DQ signals.

Fig.5 Calculated optimal DQS output delays for each clock phase

Fig.5 Calculated optimal DQS output delays for each clock phase

The clock phase is scanned over the full period and for each phase the marginal (switching from 0×00 to 0×01) DQS output delay is measured for each of the byte lanes. This procedure directly results in the optimal values of the DQS output delay values, there is no need to shift them by a half-period. Fig. 5 shows the calculated by linear interpolation values of the DQS output delays for each phase. To increase the range of DQ vs. DQS delay measurements, the DQS output signals are allowed to slightly deviate from the optimal – Fig. 5 shows “early” and “late” branches and the amount of deviation.

The similar calculation is performed later once more time when additional data from co-measurement of DQ output delays and DQS output delays becomes available. At that stage it is possible to account for non-uniform fine delay steps of DQS output lines.

Step 4: Fixed pattern measurements

DDR3 memory devices have another special operational mode intended for timing set up that does not depend on actual data being written to the memory or read back. This is reading a predefined pattern from the device, currently only one pattern is defined – it is just alternating 0-1-0-1… on each of the data lines simultaneously. In this step the 11 of the 8-word bursts are read from the memory, then only the middle 8 bursts are processed, so there is no dependence on the (yet) wrong timing settings that result in the wrong synchronization of the data bursts. That provides 64 data words, half being in even (starting from 0) positions that are supposed to be zeros, and half in odd ones (should read all 1-s), and then total number of ones is calculated for each data bit for odd and even slots – 16 pairs of numbers in the range of zero to 32. These results depend on the difference between delays in the data and data strobe signal paths and allow detection of 4 different events in each data line: alignment of the leading edge on the DQ line to the leading edge of the DQS signal (as seen at the de-serializer inputs), trailing edge of the DQ to leading one of DQS and the same leading and trailing DQ to the trailing DQS. They are measured as transitions from 0 to 1 and from 1 to zero separately for even and odd data samples.

Fig.6 Measured (marginal) and calculated (optimal) DQ input delays vs. DQS input delays

Fig.6 Measured (marginal) and calculated (optimal) DQ input delays vs. DQS input delays

Most results have 0 or 32 values (all data words are read 0 or 1), but some provide intermediate “analog” results when corresponding words are read differently, depending on some uncontrolled factors. Later processing assumes that the difference from the middle value (16) is proportional to the difference between the measured (by the settings) delay value and the actual one. Additionally if the number of such analog samples is sufficient, it is possible to process only them and discard “binary” (all 0-s/all 1-s transitions).

This measurement can be made with any clock phase setting. Even as normally there is a certain relation between the phase and DQS delay (measured in the next step), wrong setting shifts read data by the full clock period or 2 bits for each DQ line, with 0-1-0-1 pattern there is no difference caused by such shift and we are discarding first and last data bursts where such shift could be noticed.

Figure 6 shows measured 4 variants for each data bit, ‘ir_*” for in-phase (DQ to DQS), DQ rising, “if” in-phase DQ falling, ‘or’ – opposite phase rising and ‘of’ – opposite phase falling. Only “analog” samples are kept. “E*” and “N*” show the calculated optimal DQ* delay for each DQS delay value. Calculation is performed with Levenberg-Marquardt algorithm with the delay model describe late in this article, the same program method is used both for input and output delays. The visible waves on the result curves are caused by the non-uniformity of the combined 32-tap main delays with the additional 5-tap fine delay elements, different amplitude of these waves is caused by the phase shift between the DQ and DQS lines (“phase” here is the fine delay (0..5) value – the full 0..159 delay modulo 5).

Step 5: Measuring DQS input delay vs. clock phase

Deserializers use both memory-synchronous clock (derived from DQS) and system-synchronous clk and clk_div, so there is a certain optimal phase shift between the two, allowing maximal deviation of the memory-synchronous input clock.

Fig.7 Measured (marginal) and calculated (optimal) DQS input delays vs. clock phase

Fig.7 Measured (marginal) and calculated (optimal) DQS input delays vs. clock phase

Data is crossing clock domains boundary at a single clock rate (2 bits at a time for each data line), so using fixed pattern of alternating 0-1-0-1… can not be used – regardless of the phase shift it will be the same “01” pair. For this reason we use actual read data command, not a special read pattern mode. Random data that is present in the memory array after power up can be used, but the program is writing a 0-0-1-1-0-0- 11… pattern for each data bit. This pattern will provide different di-bit value in each DQ line, even if the write DQ to DQS timing is not yet determined, so the actual data can be any of X-0-X-1-X- 0… where X can quasi-randomly be any of 0 or 1. The pattern is recorded once, then the data is read with different DQS input delays (DQ input delays are set according to step 4 results), comparing only the middle portion with the beginning/end discarded as before. The marginal DQS delay is detected as the value when the read data changes from the original value.

Figure 7 shows results of such measurements as well as the calculated optimal input delays for DQS lines. This calculation uses both Step 5 (DQS vs. phase) and Step 4 (DQ vs. DQS) measuremts and accounts for the fine delay non-uniformity.

Step 6: DQ to DQS output delays measurements

Fig.8 Measured (marginal) and calculated (optimal) DQ input delays vs. DQS output delays

Fig.8 Measured (marginal) and calculated (optimal) DQ input delays vs. DQS output delays

This measurement is performed similarly to step 4 when DQ to DQS input delays relation was probed with a fixed pattern readout mode. Now we already have known settings for the memory read operation and can rely on it to adjust write mode (output) delays. Alternating 0-1-0-1 sequence in every line similar to the pattern mode is recorded with various DQS output delay values, for each DQS delay appropriate phase and address/command delay values are used. Input delays (for DQS and DQ) are set for each phase using data from the previous steps and the data written with different DQ output delay is read back, then processed in the same way as in Step 4.

Figure 8 presents the relation between DQ and DQS output delays, and the result of combining Step 6 measurements with Step 3 (write levelling) – optimal DQ and DQS output delay values for different clock phase can be seen on Figure 9 that shows all the delays. Allowing some deviation from the DQS to clock alignment (this requirement is more relaxed than DQ-to-DQS delays) results into 2 alternative solutions for the same phase shift near phase=95, use of the higher memory clock rates will result in more of such multi-solution areas even without deviation from the optimal values.

Step 7: Measuring individual output delays for all address and bank lines

Having almost calibrated read and write memory operations it is now possible to set up output delays for each of the remaining address and bank lines (so far only A[7] was measured, other lines were just assumed to be the same). This measurement is done with writing some “good” pattern to a specific bank/row/column page (column address uses the low bits of the row address), and a “bad” data to all pages different by 1 of the address or bank bits. For this test the refresh sequence (it is loaded by the software, it is not hard-wired in the HDL code) was modified to provide specified data on the bank/address lines that is “don’t care” for this operation. These values are set to be inverted values to the “good” address, and the refresh command was manually requested before the read operation, making sure that the command will cause all the address/bank bits to be inverted.

All the phase values are scanned, for each phase the command and address delays are set to the optimal values as defined so far, and only one line at a time delay was modified to find the marginal value that causes the readout of the wrong data block.

This measurement is performed twice – fist with “good” address of all zeros, then – with all ones and results averaged for low → high and high → low address line transitions.

Step 8: Selecting valid parameter combinations for readout and write modes

Fig.9 All delays vs. clock phase

Fig.9 All delays vs. clock phase

Figure 9 combines all the data acquired so far as a function of the clock phase shift. Most of the delays do not change when the new bitstream is generated after the modification of the HDL code – the involved delays are defined by the fixed I/O circuitry and PCB/package routing. Only two of the signals involve FPGA fabric routes – DQS input signals that include BUFIO clock buffers, these buffers can be selected differently and routed differently by the tools. These signals also show the largest difference one the graph (two pairs of the green lines – solid and dashed).

There are additional requirements that are not shown on the Figure 9. DQ signals from the memory should arrive to the deserializer ¼ clock period earlier than the leading edge of the first DQS pulse, not 1 ¼ or not ¾ later – the measurements so far where made to the nearest clock period. Memory device generates exactly the required number of DQS transitions, so if the data arrives 1 clock too early, then the first two words will be lost, if it arrives 1 clock too late – the last two words will be lost.

Fig.10 All delays vs. clock phase, filtered to satisfy period-correct write/read conditions

Fig.10 All delays vs. clock phase, filtered to satisfy period-correct write/read conditions

For this final step the alternative variants of the setting that differ by the full clock periods are selected and tested. First the block with incremented (each word is the previous one plus 1) data is recorded and then the smaller block completely inside the recorded one and not using the first/last bursts is read back. The write mode is not yet set up, so the first/last recorded burst can not be trusted, but the middle ones should be recorded incrementally, so any differences from this pattern have to be caused by the incorrect readout settings.

After removing invalid parameter combinations defining the readout mode we can trust that the full block readout has all the words valid. Then we can do the same for the write mode and check which of the variants (if any) provide correct memory write operation. In the test case (one particular hardware sample and one clock frequency there was exactly one variant (as shown on the Figure 10) and the final settings can use the center of the range. With higher clock frequency several solutions may be possible – then other factors can be considered, such as trying to minimize the delays of the most timing-critical signals (DQ, DQS) to reduce dependence on the possible delay vs. temperature variations (not measured yet).

Model and parameters of the input/output delay elements

Processing of the measurement results in steps 4 and 6 involved using a delay model defined by a set of parameters and then finding the values of these parameters to best fit the measurement results.
Each data byte lane is independent from the other, so for each of the 4 groups (two for output and two for input) there are nine signals – one DQS and 8 DQ signals. Each delay consists of a 32-tap delay line with the datasheet delay of 78 ps per tap and a 5-tap delay with nominal 10 ps step. Our model represents each 32-tap delay as linear with tDQ[7:0] delays corresponding to a tap 0 and tSDQ[7:0], tSDQS – individual scale (measured in picoseconds per step). Fine delay steps turned out to be very non-uniform (in some cases even non-monotonic) so each of the 4 delay values (for 5-tap delay) is assigned an individual parameter – 4 for DQS (tFSDQS) and 32 for DQ (tFSDQ).

Procedure of measuring all 4 combinations of leading/trailing edges of the strobe and data makes it possible to calculate duty cycle for each of the 9 signals – tDQSHL (difference between time high and time low for the DQS signal) and eight tDQHL[7:0] for the similar differences for each of the data lines. Additional parameter was used to model the uncertainty of the measurement results (number of ones or zeros of the 32 samples) as a function of the delay difference from the center (corresponding to 50% of the zeros and ones). This parameter (anaScale in the program code) is measured in picoseconds and means how much the delay should be changed to switch form all 0 to all 1 (using simple piecewise linear approximation).

Parameter fitting is implemented using Levenberg-Marquardt algorithm, initial scale values use dataseeet data, initial delays are estimated using histograms of the acquired data (to separate data acquired with different integer number of clock cycles shift), other parameters are initialized to zeros. Below is a sample of the program output – algorithm converges rather quickly, getting to the remaining root mean square error (difference between the measured and modeled data) of about 10ps:
Before LMA (DQ lane 0): average(fx)= 40.929028ps, rms(fx)=68.575944ps
0: LMA_step SUCCESS average(fx)= -0.336785ps, rms(fx)=19.860737ps
1: LMA_step SUCCESS average(fx)= -0.588623ps, rms(fx)=11.372493ps
2: LMA_step SUCCESS average(fx)= -0.188890ps, rms(fx)=10.078727ps
3: LMA_step SUCCESS average(fx)= -0.050376ps, rms(fx)=9.963139ps
4: LMA_step SUCCESS average(fx)= -0.013543ps, rms(fx)=9.953569ps
5: LMA_step SUCCESS average(fx)= -0.003575ps, rms(fx)=9.952006ps
6: LMA_step SUCCESS average(fx)= -0.000679ps, rms(fx)=9.951826ps

Tables 1 and 2 summarize parameters of delay models for all input and data/strobe output signals. Of course these parameters do not describe the pure delay elements of the FPGA device, but a combination of these elements, I/O ports and PCB traces, delays in the DDR3 memory device. The BUFIO clock buffers and routing delays also contribute to the delays of the DQS input paths.


Table 1. Input delays model parameters
parameter number of values average min max max-min units
tDQSHL 2 4.67 -35.56 44.9 80.46 ps
tDQHL 16 -74.12 -128.03 -4.96 123.07 ps
tDQ 16 159.87 113.93 213.44 99.51 ps
tSDQS 2 77.98 75.36 80.59 5.23 ps/step
tSDQ 16 75.18 73 77 4 ps/step
tFSDQS 8 5.78 -1.01 9.88 10.89 ps/step
tFSDQ 64 6.73 -1.68 14.25 15.93 ps/step
anaScale 2 17.6 17.15 18.05 0.9 ps

Table 2. Output delays model parameters
parameter number of values average min max max-min units
tDQSHL 2 -114.44 -138.77 -90.1 48.66 ps
tDQHL 16 -23.62 -96.51 44.82 141.33 ps
tDQ 16 1236.69 1183 1281.92 98.92 ps
tSDQS 2 74.89 74.86 74.92 0.06 ps/step
tSDQ 16 75.42 69.26 77.22 7.96 ps/step
tFSDQS 8 6.16 2.1 11.32 9.22 ps/step
tFSDQ 64 6.94 0.19 19.81 19.63 ps/step
anaScale 2 8.18 5.38 10.97 5.59 ps

Features I would like to see improved in the future Xilinx devices

“Finedelay” 5-delay delay stage in IDELAY2 and ODELAY2 elements

I noticed the existence of these 5-tap delay elements in the utilization report of Xilinx Vivado tools – they do not seem to be documented in the Libraries Guide. I assume that the manufacturer was not very happy with their performance (the average measured value of the delay per tap turned out to be less than 7 ps so even the last tap output does not provide delay of the half of the 32-tap step, and non-uniformity of the delays makes it difficult to use in the simple hardware-based delay adjustment modules. But I like this option – it almost gives one extra bit of delay and as we are using software for delay calibration it is not a problem to have even a non-monotonic delay stage. So I would like to see this feature improved – added more taps to completely cover the full step of the coarse delay stage in the future devices, and have this nice feature documented, not hidden from the users.

Use of the internal voltage reference and the duty cycle correction

Internal reference voltage option was used in the tested circuitry because of the limited number of pins to implement a single-bank 16-bit wide memory interface, and the Xilinx datasheet limits memory clock to just 400 MHz for such configuration. Measurements show that there is a bias of -74.12ps on the duty cycle that may be caused by variation of the internal reference voltage, but the spread of the delays (123 ps) is still larger. Of course it is difficult to judge without having statistics on multiple units, but I suppose that the handicap of using internal reference is not that significant. And even 123ps is not that big as tDQHL was measured as a difference of duration high minus duration low, so if one transition edge is fixed, the other will have an error of just half of this value – less than a coarse (32-tap) delay when calibrated at 200 MHz (fine delay is possible to calibrate with 300MHz).

It would be nice to have at least a couple of bits in the delay primitives dedicated to the duty cycle correction of the delay elements that can be implemented as selective AND or OR the delay tap output with the previous one.

by andrey at April 25, 2015 12:24 AM

April 23, 2015

Elphel

Kernel development for OpenEmbedded with Eclipse

Eclipse with C Development Tool (CDT) is a very powerful and feature-rich IDE for developing embedded Linux applications, such as Elphel393 camera. CDT includes CODAN — static code analysis tool which helps user to track possible problems in his code without compiling it, and Code Indexer, giving an auto-complete and code navigating (F3) features. They work independently from compiler, thus parsing the code in the same manner as compiler does is essential for producing meaningful results. As project grows, the interconnections between its parts tend to become more and more complicated, and maintaining the congruency of code processing for compiler and CODAN/Code Indexer becomes a non-trivial task. In the Internet, the most frequent recommendation for users who wish to develop Linux kernel with Eclipse is to disable CODAN feature since messy false error markers make it practically unusable. The situation becomes even worse for developers using external build tools (such as OpenEmbedded’s BitBake) as CODAN relies on output of a CDT-integrated build system to find correct way of code parsing. Anyway, embedded Linux applications usually involve kernel development, so we’ll try to find a practical approach to get the power of CODAN and Code Indexer into our hands.


Preparing the source code

I assume Poky image build environment is already set up. More info can be found here.

Main source of analysis errors are incorrect include paths, large number of unused source files which don’t contribute to build and break the index by redefining already defined symbols, and additional parameters that don’t present in a code and are transmitted to compiler via '-D' and '-include' flags. We can get all this data from build output. This will require a specific BitBake recipe and a parser script (the script is written in Python).

In Elphel, we use a specially arranged project tree for kernel development — it allows us to plug developed drivers and patches to any kernel used by BitBake with a number of symlinks. Two sets of symlinks allow BitBake to “see” developed source files while compiling the kernel and Eclipse to “see” the main kernel source code. To create this project tree, navigate to poky/ and run:

git clone https://github.com/Elphel/linux-elphel.git

Required links are described in a kernel build recipe and created by BitBake during the ‘unpack’ task. Build is needed to produce all automatically generated header files.

. ./oe-init-build-env
bitbake linux-xlnx -c clean -f
bitbake linux-xlnx -c unpack -f
bitbake linux-xlnx -f

Setting up the Eclipse project
Created project tree already contains prepared project settings file (.cproject). If you’re interested in Linux development for Elphel393 camera, you can use it with a couple of easy initial steps described in README.md. If you’re interested in tuning your own project, I’ll give a summary of required settings in this blog.

Run Eclipse. Some additional heap memory may be required for indexing the kernel source:

./eclipse -vmargs -Xmx4G

  • File → New → C Project
    • Name = linux-elphel (this is hard-coded in a parser script so if you want to change it, edit the script as well)
    • Uncheck “Use default location”
    • Location = path to linux-elphel/ project directory
    • Project type = Makefile project → Empty Project
    • Toolchain = Linux GCC
    • [Next] → Advanced Settings (OK to overwrite)
  • C/C++ General → Preprocessor Include Paths → Entries → GNU C → CDT User Settings
    • [Add...] → Select “Preprocessor macros file” → linux/include/generated/autoconf.h → [OK]
    • [Add...] → Select “Preprocessor macros file” → linux/include/linux/compiler.h → [OK]
  • C/C++ General → Indexer
    • Check “Enable project specific setttings”
    • Check “Enable indexer”
    • Uncheck “Index source files not included in the build”
    • Uncheck “Index unused headers”
    • Check “Index header variants”
    • Uncheck “Index source and header files opened in editor”
    • Uncheck “Allow heuristic resolution of includes”
    • Set size of files to be skipped >100MB (effectively disabling this feature)
    • Uncheck all “Skip…” options
  • C/C++ General → Paths and symbols → Includes → GNU C → [Add...] → [Workspace] → /linux-elphel/linux/include → [OK] → [Ok]
  • C/C++ General → Paths and symbols → Source Location → [Add Folder...] → select linux/ → [OK]
    • In the same window delete default source location entry (/linux-elphel)
  • C/C++ General → Paths and symbols → Symbols → GNU C → [Add...] → Name=__GNUC__, value=4 → [OK]
  • C/C++ General → Preprocessor Include Paths → Providers → Uncheck all except CDT User Setting Entries and CDT Managed Build Setting Entries
  • [OK] to close Advanced Settings window → Finish.

The project is created. Close Eclipse for now.

Running the parser
You’ll need a modified recipe file and a parser script. To make BitBake output all the information required, add a variable assignment to the recipe:

EXTRA_OEMAKE = "${_MAKEFLAGS}"

Download the parser script into poky/build/ directory:

git clone https://github.com/Elphel/kernel-bitbake-parser.git

This script is heavily dependent on the project structure and has to be customized for your project. Feel free to ask if you have any questions about it. Build kernel with specific set of flags (it’ll take a while) and parse the output:

export _MAKEFLAGS="-s -w -j1 -B KCFLAGS='-v'"
export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE _MAKEFLAGS"
bitbake linux-xlnx -c clean -f
bitbake linux-xlnx -c compile -v -f|python3 ./kernel-bitbake-parser/kbparse.py

The output consists of 4 sections — Define statements, Include paths, Source paths and Extra include files. First 3 of them are formatted as XML tags allowing to copy’n'paste them directly into respective nodes of a .cproject file. Script will attempt to automatically modify .cproject file as well. Extra includes have to be manually added from Eclipse. (C/C++ General → Preprocessor Include Paths → Entries → GNU C → CDT User Settings → [Add...] → Select “Include file” → Copy the path from parser output → [OK])

Run Eclipse:

./eclipse -vmargs -Xmx4G

Project → C/C++ Index → Rebuild.

The result is less than 0.005% of unresolved symbols (this can be seen from the Error Log, Window → Show view → Other… → Error Log) and no error markers from CODAN.

by Yuri Nenakhov at April 23, 2015 10:47 PM

April 18, 2015

Free Electrons

Linux 4.0 released, Free Electrons #6 contributing company

Linus Torvalds has released 4.0 a few days ago, deciding to increment the major number version just because he cannot count up to 20 with his fingers and toes. As usual, LWN gave an excellent coverage of the merge window for 4.0 (which at the time was expected to be called 3.20): first part, second part and third part. LWN also published an article with development statistics about the 4.0 cycle.

According to the LWN statistics, Free Electrons is the 6th contributing company in number of patches for the 4.0 cycle.

Here is in detail, all our commits to the Linux 4.0 release:

by Thomas Petazzoni at April 18, 2015 02:02 PM

April 15, 2015

Bunnie Studios

The Heirloom Laptop’s Custom Wood Composite

The following is an excerpt from a recent Novena backer update that just got published. I thought the tech bits, at least, might be interesting to a broader audience so I’m republishing them here:


With mainline laptop production finally humming along, bunnie was able to spend a week in Portland, Oregon working side by side with Kurt Mottweiler to hammer out all of the final open issues on the Heirloom devices.

We’re very excited about and proud of the way the Heirloom laptops are coming together. In a literal sense, Heirloom laptops are “grown” – important structural elements come from trees. While we could have taken the easy route and made every laptop identical, we felt it would be much more apropos of a bespoke product to make each one unique by picking the finest woods and matching their finish and color in a tasteful fashion. As a result, no two Heirloom laptops will look the same; each will be beautiful in its own unique way.

There’s a lot of science and engineering going into the Heirloom laptops. For starters, Kurt has created a unique composite material by layering cork, fiberglass, and wood. To help characterize the novel composite, some material samples were taken to the Center for Bits and Atoms at MIT, where Nadya Peek (who helped define the Peek Array) and Will Langford characterized the performance of the material. We took sections of the wood composite and performed a 3-point bend test using a Instron 4411 electromechanical material testing machine. From the test data, we were able to extract the flexural modulus and flexural strength of the material.


Heirloom composite material loaded into the testing machine

I’m not a mechanical engineer by training, so words like “modulus” and “specific strength” kind of go over my head. But Nadya was kind enough to lend me some insight into how to think about materials in this context. She pointed me at the Ashby chart, which like some xkcd comic panels, I could stare at for an hour and still not absorb all the information contained within.

For example, the Ashby chart above plots Young’s Modulus versus density of many materials. In short, the bottom left of the chart has bendy, light materials – like cork – and the top right of the chart has rigid, heavy materials, like Tungsten. For a laptop case, we want a material with the density of cork, but the stiffness of plastic. If you look at the chart, wood products occupy a space to the left of plastics, meaning they are less dense, but they have a problem: they are weak perpendicular to the grain, and so depending on the direction of the strain, they can be as yielding as polyethene (the stuff used to make plastic beverage bottles), or stiffer than polycarbonate (the stuff layered with glass to make bulletproof windows). Composite materials are great because they allow us to blend the characteristics of multiple materials to hit the desired characteristic; in this case, Kurt has blended cork, glass fiber, and wood.

The measurements of the Heirloom composite show a flexural strength of about 33 MPa, and a flexural modulus of about 2.2-3.2 GPa. The density of the material is 0.49 g/cm3, meaning it’s about half the density of ABS. Plotting these numbers on the Ashby chart shows that the Heirloom composite occupies a nice spot to the left of plastics, and provides a compromise on stiffness based on grain direction.

The red circle shows approximately where the Heirloom composite lands. To be fair, measurements still revealed some directional sensitivity to the composite; depending on the grain, the modulus varies from about 2.2GPa to 3.2 GPa (and the diameter of the red circle encompasses this variability); but this is a much tighter band than the 10x difference in modulus indicated for pure woods.

Another thing to note is that during testing, the material didn’t fail catastrophically. Above are the graphs of load vs. extension as plotted by the Instron testing machine. Even after bending the material past its peak load, it was still mostly intact and providing resistance. This result is a bit surprising; we had expected the material, like normal wood, would break in two once it failed. Furthermore, after we reset the test, the material bounced back to its original shape; even after bending by over 10mm, once the load was removed you could barely tell it went through testing. This high fracture toughness and resilience are desireable properties for a laptop case.

Of course, there’s nothing quite like picking up the material, feeling its surprising lightness, and then trying to give it a good bend and being surprised by its rigidity and ruggedness. The Heirloom backers will get the privilege of feeling this firsthand; for the rest of us, we’ll have to settle with seeing circles on Ashby charts and graphs on computer screens.


If you want to see more photos of the Heirloom laptop coming together, check out the image gallery at the bottom of the official Crowd Supply update!

by bunnie at April 15, 2015 02:26 AM

April 07, 2015

Free Electrons

Embedded Linux Conference slides from Free Electrons

Audience at ELC 2015The Free Electrons engineering team is back from a busy week at the Embedded Linux Conference 2015 in San Jose, California, last week. During this conference, we presented several talks, a BoF, and participated to the technical showcase with a Buildroot related demo:

  • Maxime Ripard gave a presentation about the DMAengine subsystem, and his slides are available as PDF.
  • Thomas Petazzoni gave a talk about The Device Tree as a stable ABI: a fairy tale?, and the slides are available as PDF.
  • Boris Brezillon gave a talk about MLC/TLC NAND support: (new ?) challenges for the MTD/NAND subsystem, the slides are available as PDF.

Our three talks were all given in front of fully packed rooms, even with a number of people standing in the room for some of them! We were glad to see that the topics we proposed did interest the ELC audience.

Boris Brezillon about support for MLC NAND in MTD

Boris Brezillon about support for MLC NAND in MTD


Thomas Petazzoni about Device Tree bindings as a stable ABI

Thomas Petazzoni about Device Tree bindings as a stable ABI. Photo by Drew Fustini.

In addition to the talk, Thomas Petazzoni organized on Tuesday last week a BoF (Birds of a feather) session on Buildroot, during which approximately 15 persons showed up even though it wasn’t announced in the official schedule. This session was useful to get some feedback from Buildroot users, and meet users and developers in person.

Finally, on Tuesday evening, during the technical show-case, we demo-ed the Buildroot capabilities using a setup that consisted in two platforms running Buildroot-generated systems: a Raspberry Pi 2 system that runs the Kodi media player software, and a Marvell Armada XP based OpenBlocks AX3 system that runs as a NAS providing contents for the media player. This demo was prepared by Buildroot contributor Yann E. Morin, and Free Electrons engineer Thomas Petazzoni. The poster presented is available as PDF or SVG, and all the instructions to rebuild the two systems are documented at http://elinux.org/Buildroot:TechShowcase2015_Demo.

Buildroot demonstration at ELC 2015 technical show case

Buildroot demonstration at ELC 2015 technical show case

Buildroot demonstration at ELC 2015 technical show case

Buildroot demonstration at ELC 2015 technical show case

In addition, it is worth mentioning that all the slides from the Embedded Linux Conference are available at http://events.linuxfoundation.org/events/embedded-linux-conference/program/schedule and http://elinux.org/ELC_2015_Presentations. The talks have been video recorded by the Linux Foundation, and hopefully unlike to what happened to the ELCE 2014 videos, the ELC 2015 videos will really appear online at some point in the future.

The location of the next Embedded Linux Conference was also announced, and it will take place in San Diego next year. It is the first time that the Embedded Linux Conference US edition moves outside of the Silicon Valley!

by Thomas Petazzoni at April 07, 2015 02:50 AM

April 04, 2015

Elphel

Trying out KiCAD

 

Introduction

curverd

Teardrops in KiCAD

We, at Elphel, are currently using proprietary software for schematic and PCB development and thus are not able to provide our customers with the “real” source files of our designs – pdf and gerber files only. Being free software and open hardware oriented company we would like to replace this software with open source analogues but were not able to accomplish this due to various limitations and inconveniences in design work-flow. We follow the progress in such projects as gEDA and KiCAD and made another attempt to use one them in our work. KiCAD seems to be the most promising design suite considering recent CERN contribution and active community support. I tried to design a simple element, a flexible printed circuit cable, using KiCAD and found out that the PCB design program lacks such useful feature as teardrops.

What are teardrops

Teardrops are often used to create mechanically stronger connections between tracks and pads/vias to prevent drill breakout during board manufacturing. This is particularly valuable when the design objects are small, as it was in my case. The figures below explain the problem:

1

Fig. 1

2

Fig. 2

3

Fig. 3

4

Fig. 4

Fig. 1 shows perfectly aligned drill hole but the final result (as on Fig. 2) can be far from perfect because of drill tool wandering or board stack misalignment during manufacturing. Relaxing specification or allowing drill breakout along the hole perimeter, as on Fig. 4, is not always possible. Adding teardrops (Fig. 3) in such cases is a good option.
The images below show misaligned drill holes on manufactured PCBs:

electronic circuit board
16513351487_5ef602a50e_z

Adding new feature

The great advantage of any open source project is the possibility to add any required feature or fix bugs on your our. I cloned KiCAD repository and dived into the source code trying to add mock up implementation of teardrops. It took some time to get acquainted with class hierarchies and internal structures. Finally, I added new option to “Tools” menu which adds teardrops to currently selected track. Two types of teardrops are implemented by the moment: curved (github link) and straight (github link). The process of selection and results are shown on the screenshots:

selection

curverd
straight

The straight teardrops are composed of two segments connecting tracks and vias. The curved teardrops are actually approximated with several short segments as KiCAD does not allow to place arcs on copper layers. There are several intentional limitations in current implementation:

  • teardrops are created for vias only
  • DRC rules are not taken into consideration during calculations
  • the ends of selected track must coincide with via center
  • no user adjustable settings

These limitations are caused by test nature of my source code and at the same time they define the fields of further development. The result obtained is good enough to be used in real applications.

Links:

https://www.flickr.com/photos/andresrueda/
https://www.flickr.com/photos/creative_stock/
https://github.com/Elphel/kicad-source-mirror

by Mikhail Karpenko at April 04, 2015 02:17 AM

March 30, 2015

Free Electrons

Linux 3.19 released, overview of Free Electrons contributions

It’s been a while that Linus Torvalds has released Linux 3.19 and we already know that the next version of Linux will be called 4.0. It’s not too late though to learn more about the 3.19 release, by reading the following three LWN articles: part 1, part 2 and part 3. KernelNewbies has also updated its page about 3.19.

In terms of statistics for the 3.19 release cycle, LWN has published an article which ranks Free Electrons the 13th contributing company, with 205 patches merged. We have been in the top 30th contributing company by number of patches for all kernel releases since Linux 3.8, a sign of our continuous involvement in the upstream kernel community.

Our most important contributions in this kernel release are:

  • For the Atmel ARM processors, numerous cleanup patches from Alexandre Belloni to prepare the platform for ARM multiplatform compliance (the possibility of building the support for Atmel ARM processors together with the support of other ARM processors in a single kernel image). From Boris Brezillon, addition of Device Tree support in the AT91 RTC driver, improvements to the AT91 irqchip driver, addition of a PWM driver for the PWM built into the Atmel HLCDC display controller, addition of Device Tree support for the AT91 hardware random number generator driver, addition of an MFD driver for the Atmel HLCDC display controller, and many other Device Tree fixes and improvements.
  • For the Marvell Berlin ARM processors, addition of USB, SATA and reset controller support. The USB support required numerous core improvements to the USB subsystem, and the addition of a specific USB PHY driver.
  • For the Marvell EBU ARM processors, Gregory Clement added USB PHY support for Armada 375, and CPU hotplug support for Armada 38x as well as several other fixes and improvements. Thomas Petazzoni added suspend to RAM support for Armada XP, fixed a serious problem in the I2C driver that required some major refactoring, and did some HW I/O coherency related fixes.
  • For the Allwinner ARM processors, Maxime Ripard did the relicensing of many Device Tree files from GPL only to GPL+X11 licenses. He also added pinctrl support on Allwinner A80.
  • After writing a dmaengine driver which was merged in 3.17, Maxime Ripard started to get involved in the dmaengine subsystem itself. He contributed a documentation for this subsystem, which was merged in Linux 3.19, as well as several fixes for dmaengine drivers.
  • Addition of a generic linux/media-bus-format.h header file, containing definitions of the various possible pixel formats. This header file was until then specific to the Video4Linux subsystem, but will start being used by the DRM/KMS subsystem. This addition was done in preparation of the introduction of a DRM/KMS driver for the AT91 HLCDC display controller (to come in Linux 4.0).
  • A few small improvements to the core DRM/KMS subsystem, also preparation work for the AT91 HLCDC display controller driver.
  • Fixes for the i.MX28 NAND flash controller driver, the gpmi-nand to properly support the raw access operations, which allow to use the userspace MTD testing utilities to validate the MTD setup. This was part of a customer project we did to assess the quality of the MTD and UBI setup on a Freescale i.MX28 custom platform.

The details of our contributions are:

by Thomas Petazzoni at March 30, 2015 03:25 PM

March 27, 2015

Zedstar

Nibble running on a Pi 2 with 2.2″ TFT

The speed bump of the Pi 2 means that nibble.io will run at similar speeds to the Banana Pi. I got of a 2.2″ TFT and soldered it onto the Pi and made a quick video. The only additional hardware used is a small USB microphone.

by john at March 27, 2015 07:01 PM

March 25, 2015

LZX Industries

Triple Video Multimode Filter 2Q 2015 Restock Orders

Triple Video Multimode Filter - Front

Triple Video Multimode Filter, domestic postage paid, $450
Triple Video Multimode Filter, international postage paid, $465

Everyone responded well to the Video Waveform Generator run we are manufacturing right now, so as we continue to use up our internal stocks of thru-hole parts I want to get another run going for Triple Video Multimode Filter. These will be handbuilt locally by my tech and myself while Darkplace Manufacturing handles new module production and currently the Color TBC restock.

Video Waveform Generator production is going smoothly and will be finished on schedule, then we’ll move into this module in late April.

Ordering is open until May 1st (or until I reach the cap of how many we can build in this batch.)
Units start shipping May 15th.
Everything fulfilled by June 1st.

by Liz Larsen at March 25, 2015 09:21 PM

Video Circuits

F & S Themerson

Here is a great early visual music film by Franciszka and Stefan Themerson from 1944/45 The Eye and the Ear.




by Chris (noreply@blogger.com) at March 25, 2015 10:57 AM

March 24, 2015

Video Circuits

Psyché Tropes & Video Circuits present an Evening of Modular Synthesis April the 4th

So I got together with Psyché Tropes to put on an event at apiary studios on the 4th of April, it should be interesting and mostly modular! There will be me and two of my favourite video syntheists doing video and three great musicians doing audio, hopefully with some cross patching for added fun and audio reactivity.



















Psyché Tropes and Video Circuits present an Evening of Modular Synthesis at Apiary Studios on Saturday 4th April 2015.
£6 adv / £8 door. No guest list. 8pm – Late.
Tickets: http://www.wegottickets.com/event/310502

Psyché Tropes is a label from the creator of Hackney Film Festival dedicated to exploring the synaesthetic intersections between sound and its visual counterpart. The label’s second live edition sees a collaborative event with Video Circuits combining the realms of audio and video modular synthesis with a very special line-up. Video Circuits is a blog and research project that takes a wide ranging approach to documenting the early years of electronic video art, visual music and computer art with a view to informing the current output of contemporary artists and musicians working in the field.

Live modular shows by

SCANNER
AUDIO DEPENDENT
THE ASTERISM

Live video modular by

ALEXANDER PEVERETT
SYNTHPUNK
CHRIS KING

with Psyché Tropes djs

SCANNER
British artist Robin Rimbaud traverses the experimental terrain between sound, space, image and form, creating absorbing, multi-layered sound pieces that twist technology in unconventional ways. From his early controversial work using found mobile phone conversations, through to his focus on trawling the hidden noise of the modern metropolis as the symbol of the place where hidden meanings and missed contacts emerge, his restless explorations have won him international admiration from amongst others, Bjork, Aphex Twin and Stockhausen.
http://scannerdot.com/

AUDIO DEPENDENT
Audio Dependent is the electronic music alias of audio visual artist, Tim Cowie. A long-time collaborator at The Light Surgeons, Cowie’s music and sound design work crosses over from electronica and techno, to contemporary classical and ambient soundscapes. He also releases music under his own name and as part of the duo Infinite Particles.
https://soundcloud.com/audio-dependent

THE ASTERISM
The Asterism is a semi-improvised solo modular synth and electronics project from Mark O Pilkington (Raagnagrok / Urthona / Teleplasmiste), constructed around organic rhythmic developments and blurring the lines between natural and unnatural sounds.
https://soundcloud.com/the-asterism


ALEXANDER PEVERETT
Alexander Peverett (b.1976) is a multi-disciplinary artist from Wigan, England. He resides in Japan and the United Kingdom. His personal work explores the fields of electronic & computer music, video art, multi-media installation, generative art and computer graphics. He works as a freelance Art Director, Computer Artist, Sound Designer and Video Director.
http://alexanderpeverett.com/

SYNTHPUNK
Synthpunk is a musician, engineer and video synthesist. His wide ranging skills and interests manifest themselves in many different ways one of which is his self-built modular video synthesizer.
http://synth-punk.blogspot.co.uk/

CHRIS KING
Chris King is an audio visual artist who primarily works with drawing, experimental animation, electronics and sound.
http://videocircuits.blogspot.co.uk/


More info at:
http://psyche-tropes.com/
http://www.apiarystudios.org/
http://videocircuits.blogspot.co.uk/

by Chris (noreply@blogger.com) at March 24, 2015 07:14 AM

Photos from Sabrina Ratté & Roger Tellier-Craig

I got to see Sabrina and Roger's amazing performance at the BFI on the 13th, here are some awful photos of Sabrina's beautiful imagery and a video Rosa took of their fantastic performance at Sonic Acts 2015 so you can also hear the incredible sounds too, even if it is a different set.
http://le-revelateur.tumblr.com/ I belive sabrina is also giving a talk soon to, info here







by Chris (noreply@blogger.com) at March 24, 2015 07:09 AM

Ewa Justka

I found some photos from the semi regular EAVI  night from November where Ewa played which reminded me to post up some of her work and a link to her great site. She often pefromes with hacked CRT televisions and Optoelectronic noise circuits, so there is a great synchronicity of sound and image. ewajustka.tumblr.com



by Chris (noreply@blogger.com) at March 24, 2015 06:33 AM

March 20, 2015

ZeptoBARS

Samsung SuperAMOLED : weekend die-shot

Updated March 20, 2015: Thanks to lucky(?) accident and new lens we managed to take much better photos of Samsung SuperAMOLED display:


October 17, 2013: Samsung's SuperAMOLED display from Galaxy S4 mini is supposed to have active matrix (i.e. control transistors are on substrate) and integrated touch sensor. Let's take a look: It seems there are at least 2 levels of barely visible interconnect (ITO?).


With few pixels glowing:


Only pixels glowing:


Half-pitch and thinnest lines are 2.5 µm. Diagonal die size is 109 mm :-)

March 20, 2015 02:32 PM

March 17, 2015

Bunnie Studios

Name that Ware, March 2015

The Ware for March 2015 is shown below.

Thanks to Dale Grover for sharing this ware! I had read about this one as a lad, but never laid hands on one…

by bunnie at March 17, 2015 04:40 PM

Winner, Name that Ware February 2015

The Ware for February 2015 is a logic board from an HP 16600 series logic analyzer. Megabytephreak is the winner, thanks for the clear analysis and also helping answer other reader’s questions about the metal fill for etch concentration normalization!

by bunnie at March 17, 2015 04:40 PM

March 13, 2015

osPID

Aaaaand we’re back

back in stock

I’m happy to announce that the osPID is now officially back in stock at Rocket Scream. There have been some improvements to the hardware (usb micro instead of mini, louder buzzer, etc,) but mostly this was about getting a more reliable supply chain in place.

Thanks to everyone for being so patient during this dry spell. The changes we’ve made should insure that moving forward, when you want an osPID you won’t have to wait.

by Brett at March 13, 2015 01:31 PM

March 09, 2015

Video Circuits

Le Révélateur: Sabrina Ratté & Roger Tellier-Craig London

So I am pretty excited to see Le Révélateur perform as part of Digital Québec, I am a great appreciator of all their work so far, both Sabrina and Rodger make some of the most beautiful work around. Link!


8 UK PREMIERES OVER TWO CONSECUTIVE NIGHTS AT THE BFI SOUTHBANK - MARCH 12 & 13

BFI Southbank’s regular Sonic Cinema strand teams up with ELEKTRA and MUTEK, two vibrant organisations from Québec, to present a bold and ambitious series of live audiovisual performances, featuring 8 UK Premieres over two consecutive nights.

Dubbed Digital Québec, some of the province’s most innovative and experimental A/V creators will be presenting their work for the very first time on British soil. Acting as a continuation of the combined ELEKTRA and MUTEK 15th anniversary event EM15 presented in Montréal in May 2014, the selection of works represent the interdisciplinary intersection of music, sound and digital art where both organizations meet.


LINEUP:

Thursday March 12
7pm
Dominique T Skoltz: y2o
Yan Breuleux: Tempêtes

9.15pm
Matthew Biederman & 4X: Physical
Herman Kolgen: Seismik + Aftershock

-

Friday March 13
7pm
Maotik & Metametric: Omnis
Woulg: Ring Buffer

9.30pm
Myriam Bleau: Soft Revolvers
Roger Tellier-Craig & Sabrina Ratté: Le Révélateur


TICKETS

Tickets available here: http://bit.ly/1DFug3S

1 show £16
2 shows the same night £25
Pass for 4 shows £40

If you wish to buy a 4-performance or 8-perfomance pass, you need to call the BFI box office or visit the venue to buy the festival passes.

www.elektramontreal.ca
mutek.org
bfi.org.uk

With the support of Conseil des arts et des lettres du Québec, ministère de la Culture et des Communications du Québec and the Québec Government Office in London.

by Chris (noreply@blogger.com) at March 09, 2015 12:44 PM

Dean Winkler

Here is a new work from Dean Winkler who has provided me with some of my favourite posts with uploads of his past work.

"An abstract meditation on global warming set to music by Low City. 1980s style analog video layering, created with modern desktop tools."
Check out his Vimeo channel for more fantastic work.


by Chris (noreply@blogger.com) at March 09, 2015 06:16 AM

March 03, 2015

Richard Hughes, ColorHug

Updating Firmware on Linux

A few weeks ago Christian asked me to help with the firmware update task that a couple of people at Red Hat have been working on for the last few months. Peter has got fwupdate to the point where we can “upload” sample .cap files onto the flash chips, but this isn’t particularly safe, or easy to do. What we want for Fedora and RHEL is to be able to either install a .rpm file for a BIOS update (if the firmware is re-distributable), or to get notified about it in GNOME Software where it can be downloaded from the upstream vendor. If we’re showing it in a UI, we also want some well written update descriptions, telling the user about what’s fixed in the firmware update and why they should update. Above all else, we want to be able to update firmware safely offline without causing any damage to the system.

So, lets back up a bit. What do we actually need? A binary firmware blob isn’t so useful, and so Microsoft have decided we should all package it up in a .cab file (a bit like a .zip file) along with a .inf file that describes the update in more detail. Parsing .inf files isn’t so hard in Linux as we can fix them up to be valid and open them as a standard key file. The .inf file gives us the hardware ID of what the firmware is referring to, as well as a vendor and a short (!) update description. So far the update descriptions have been less than awesome “update firmware” so we also need some way of fixing up the update descriptions to be suitable to show the user.

AppStream, again, to the rescue. I’m going to ask nice upstreams like Intel and the weird guy who does ColorHug to start shipping a MetaInfo file alongside the .inf file in the firmware .cab file. This means we can have fully localized update descriptions, along with all the usual things you’d expect from an update, e.g. the upstream vendor, the licensing information, etc. Of course, a lot of vendors are not going to care about good descriptions, and won’t be interested in shipping another 16k file in the update just for Linux users. For that, we can actually “inject” a replacement MetaInfo file when we curate the AppStream metadata. This allows us to download all the .cab files we care about, but are not allowed to redistribute, run the appstream-builder on them, then package up just the XML metadata which can be consumed by pretty much any distribution. Ideally vendors would do this long term, bu you need got master versions of basically everything to generate the file, so it’s somewhat of a big ask at the moment.

So, we’ve now got a big blob of metadata we can read in GNOME Software, and show to Fedora users. We can show it in the updates panel, just like a normal update, we just can’t do anything with it. We also don’t know if the firmware update we know about is valid for the hardware we’re running on. These are both solved by the new fwupd project that I’ve been hacking on for a few days. This exit-on-idle daemon allows normal users to apply firmware to devices (with appropriate PolicyKit checks, typically the root password) in a safe way. We check the .cab file is valid, is for the right hardware, and then apply the update to be flashed on next reboot.

A lot of people don’t have UEFI hardware that’s capable of using capsule firmware updates, so I’ve also added a ColorHug provider, which predictably also lets you update the firmware on your ColorHug device. It’s a lot lower risk testing all this super-new code with a £20 EEPROM device than your nice shiny expensive prototype hardware from Intel.

At the moment there’s not a lot to test, we still need to connect up the low level fwupdate code with the fwupd provider, but that will be a lot easier when we get all the prerequisites into Fedora. What’s left to do now is to write a plugin for GNOME Software so it can communicate with fwupd, and to write the required hooks so we can get the firmware upgrade status as a notification for boot+2. I’m also happy to accept patches for other hardware that supports updates, although the internal API isn’t 100% stable yet. This is probably quite interesting for phones and tablets, so I’d be really happy if this gets used on other non-Fedora, or non-desktop usecases.

Comments welcome. No screenshots yet, but coming soon.

by hughsie at March 03, 2015 07:29 PM

March 02, 2015

Video Circuits

C.E. Burnett

A recent article on Paleofuture brought to my attention the work of C.E. Burnett an engineer at RCA's  research lab during the 1930s. This must be a very early example of cathode ray tubes being used for pattern generation and certainly predates many more well known media art pioneers. I wonder if he ever spoke to Ben F. Laposky another early pioneer in a related technique.



























sources:
https://books.google.co.uk/books?id=vSgDAAAAMBAJ&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false
http://www.americanradiohistory.com/Archive-Radio-Craft/1930s/Radio-Craft-1938-07.pdf

by Chris (noreply@blogger.com) at March 02, 2015 10:42 AM

Zoran Radovic

Zoran Radovic has been working with pendulums, plotters, lasers and CRT displays since the 1960s. A recent post by an online friend highlighted the fact that his studio is being sold off, I noticed some plotter art on the wall which lead me to check out his great site detailing his fantastic work. www.radovic-art.de he details his various systems building on his ideas and demonstrating how some of his systems work. Please go read his site for more info! 






















































Here are a few more links with some of his work


by Chris (noreply@blogger.com) at March 02, 2015 08:16 AM

February 28, 2015

Bunnie Studios

Name that Ware, February 2015

The Ware for February 2015 is shown below.

Eep! I’m late! I blame Chinese New Year.

This one was a tough one to crop: too much makes it too obvious, too little makes it impossible to guess. However, I’m betting that someone out there could probably recognize this ware even if I downsampled all of the part numbers and manufacturer’s logos.

Thanks again to dmo for sharing this ware. I’ll miss visiting your lab!

by bunnie at February 28, 2015 06:02 PM

Winner, Name that Ware January 2015

Judging this one was tough. There were a lot of perfectly good guesses (and some pretty hilarious ones :), but because the advertised purpose of this ware is so weird, sound engineering reasoning need not apply.

What I’m told is that you install this on an electric bike to prevent the motor from burning out. I….don’t really think that’s effective, nor do I really believe it. At the very least, stacking capacitors like this while connecting them with thin copper traces to a terminal block and then wiring them with a long pair of wires to a battery seems to nullify any benefit of equalizing the ESR of capacitors by using a banked array of different values.

Although I think Jeff’s explanation (use as a power filtering cap in car audio) is a much more likely reason…I liked ingo’s thought process in reviewing the ware — knowledgeable, yet skeptical. So I’ll declare ingo as the winner…congrats, email me for your prize!

by bunnie at February 28, 2015 06:01 PM

February 26, 2015

Video Circuits

New Australian Experimental Video Resource

So a while back I heard rumblings about this and have been meaning to post this for a while, Stephen Jones (one of the pioneers of media art in Aus) designed  the Supernova 12, a system owned by Jeffrey Siedler who has very kindly donated it to a new experimental video lab set up By Tom Ellard (of severed heads) and Ant Banister at the University of New South Wales, Other Stephen Jones machines have also been resurrected and integrated with some newer devices and at some point in the future hopefully we will see some new work! I believe Ed and Liz of LZX and Pia VanGelder are also lending a hand  (thanks to Ant for the Photos) and Tom for his blog posts http://tomellard.com/wp/2013/09/operation-big-iron/ http://tomellard.com/wp/2014/09/update-to-big-iron-fingers-crossed/



by Chris (noreply@blogger.com) at February 26, 2015 02:20 PM

February 23, 2015

ZeptoBARS

Nordic NRF24L01+ - real vs fake : weekend die-shot

Nordic NRF24L01+ (NRF24L01P) is a very popular 2.4Ghz transceiver used in countless consumer products. Not surprising that we've came across it's fake.

Genuine: This chip was extracted from "expensive" (~10$) RF module with additional RF amplifier chip:


Die size - 1876x1761 µm, 250nm technology.

Nordic logo on the die:




Compatible/counterfeit: This chip was extracted from "cheap" RF module (1$):

Die size - 2014x1966 µm, 350nm technology.

Resume:

Chip marking is similar, though not identical (genuine one on the right):

Fake chip has quite thin marking. Also, text jumps significantly from chip to chip (point stays in place).

Despite there were no functional differences reported (yet), one could expect that 350nm compatible chip will have slightly higher power consumption and slightly lower sensitivity. If only this chip was marked properly (Like SI24R1 - one of compatible chips) as compatible - that would have been totally legitimate business. But currently designers, manufacturers and end users are mis-leaded.

February 23, 2015 04:10 AM

February 17, 2015

LZX Industries

Video Waveform Generator 1Q 2015 Restock Orders

Video Waveform Generator Video Waveform Generator
We are about to launch a production run of Video Waveform Generators. I know there are a ton of you who have been patiently waiting for these to become available again, so we’d like to offer some special pricing if you order before the production run starts. Use the below Buy Now links to place your order, or contact us directly if you have any questions.

Pre-sale ordering for Video Waveform Generator is now closed. Thank you to everyone who placed an order! Modules are now being manufactured.

by Liz Larsen at February 17, 2015 03:32 PM

February 13, 2015

Richard Hughes, ColorHug

16F1454 RA4 input only

To save someone else a wasted evening, RA4 on the MicroChip PIC 16F1454 is an input-only pin, not I/O like stated in the datasheet. In other news, I’ve prototyped the ColorHug ALS on a breadboard (which, it turns out was a good idea!) and the PCB is now even smaller. 12x19mm is about as small as I can go…

by hughsie at February 13, 2015 09:44 AM

February 08, 2015

Bunnie Studios

A Tale of Two Zippers

Recently, Akiba took me to visit his friend’s zipper factory. I love visiting factories: no matter how simple the product, I learn something new.

This factory is a highly-automated, vertically-integrated manufacturer. To give you an idea of what that means, they take this:


Ingots of 93% zinc, 7% aluminum alloy; approx 1 ton shown

and this:

Compressed sawdust pellets, used to fuel the ingot smelter

and this:

Rice, used to feed the workers

And turn it into this:

Finished puller+slider assemblies

In between the input material and the output product is a fully automated die casting line, a set of tumblers and vibrating pots to release and polish the zippers, and a set of machines to de-burr and join the puller to the slider. I think I counted less than a dozen employees in the facility, and I’m guessing their capacity well exceeds a million zippers a month.

I find vibrapots mesmerizing. I actually don’t know if that’s what they are called — I just call them that (I figure within minutes of this going up, a comment will appear informing me of their proper name). The video below shows these miracles at work. It looks as if the sliders and pullers are lining themselves up in the right orientation by magic, falling into a rail, and being pressed together into that familiar zipper form, in a single fully automated machine.



720p version

If you put your hand in the pot, you’ll find there’s no stirrer to cause the motion that you see; you’ll just feel a strong vibration. If you relax your hand, you’ll find it starting to move along with all the other items in the pot. The entire pot is vibrating in a biased fashion, such that the items inside tend to move in a circular motion. This pushes them onto a set of rails which are shaped to take advantage of asymmetries in the object to allow only the objects that happen to jump on the rail in the correct orientation through to the next stage.

Despite the high level of automation in this factory, many of the workers I saw were performing this one operation:



720p version

This begs the question of why is it that some zippers have fully automated assembly procesess, whereas others are semi-automatic?

The answer, it turns out, is very subtle, and it boils down to this:

I’ve added red arrows to highlight the key difference between the zippers. This tiny tab, barely visible, is the difference between full automation and a human having to join millions of sliders and pullers together. To understand why, let’s review one critical step in the vibrapot operation.

We paused the vibrapot responsible for sorting the pullers into the correct orientation for the fully automatic process, so I could take a photo of the key step:

As you can see, when the pullers come around the rail, their orientation is random: some are facing right, some facing left. But the joining operation must only insert the slider into the smaller of the two holes. The tiny tab, highlighted above, allows gravity to cause all the pullers to hang in the same direction as they fall into a rail toward the left.

The semi-automated zipper design doesn’t have this tab; as a result, the design is too symmetric for a vibrapot to align the puller. I asked the factory owner if adding the tiny tab would save this labor, and he said absolutely.

At this point, it seems blindingly obvious to me that all zippers should have this tiny tab, but the zipper’s designer wouldn’t have it. Even though the tab is very small, a user can feel the subtle bumps, and it’s perceived as a defect in the design. As a result, the designer insists upon a perfectly smooth tab which accordingly has no feature to easily and reliably allow for automatic orientation.

I’d like to imagine that most people, after watching a person join pullers to sliders for a couple minutes, will be quite alright to suffer the tiny bump on the tip of their zipper to save another human the fate of having to manually align pullers into sliders for 8 hours a day. I suppose alternately, an engineer could spend countless hours trying to design a more complex method for aligning the pullers and sliders, but (a) the zipper’s customer probably wouldn’t pay for that effort and (b) it’s probably net cheaper to pay unskilled labor to manually perform the sorting. They’ve already automated everything else in this factory, so I figure they’ve thought long and hard about this problem, too. My guess is that robots are expensive to build and maintain; people are self-replicating and largely self-maintaining. Remember that third input to the factory, “rice”? Any robot’s spare parts have to be cheaper than rice to earn a place on this factory’s floor.

However, in reality, it’s by far too much effort to explain this to end customers; and in fact quite the opposite happens in the market. Because of the extra labor involved in putting these together, the zippers cost more; therefore they tend to end up in high-end products. This further enforces the notion that really smooth zippers with no tiny tab on them must be the result of quality control and attention to detail.

My world is full of small frustrations similar to this. For example, most customers perceive plastics with a mirror-finish to be of a higher quality than those with a satin finish. While functionally there is no difference in the plastic’s structural performance, it takes a lot more effort to make something with a mirror-finish. The injection molding tools must be painstakingly and meticulously polished, and at every step in the factory, workers must wear white gloves; mountains of plastic are scrapped for hairline defects, and extra films of plastic are placed over mirror surfaces to protect them during shipping.

For all that effort, for all that waste, what’s the first thing a user does? Put their dirty fingerprints all over the mirror finish. Within a minute of coming out of the box, all that effort is undone. Or worse yet, they leave the protective film on, resulting in a net worse cosmetic effect than a satin finish. Contrast this to a satin finish. Satin finishes don’t require protective films, are easier to handle, last longer, and have much better yields. In the user’s hands, they hide small scratches, fingerprints, and bits of dust. Arguably, the satin finish offers a better long-term customer experience than the mirror finish.

But that mirror finish sure does look pretty in photographs and showroom displays!

by bunnie at February 08, 2015 08:43 PM

Altus Metrum

keithp's rocket blog: Altos1.6

AltOS 1.6 — TeleDongle v3.0 support and bug fixes

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

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

This is a major release of AltOS, including support for our new TeleDongle v3.0 board and a selection of bug fixes

AltOS Firmware — TeleDongle v3.0 added along with some fixes

Our updated ground station, TeleDongle v3.0, works just like the original TeleDongle, but is an all-new design:

  • CC1200 radio chip is about 5dB more sensitive than TeleDongle's CC1111.

  • LPC11U14 CPU can be reprogrammed over the USB link.

AltOS Bug Fixes

We also fixed a few bugs in the firmware:

  • Make sure the startup flight computer beeps are consistent. Sometimes, it was taking long enough to beep out the battery voltage that the flight computer state was changing in the middle, causing a bit of confusion.

  • Change TeleDongle's LED indicators during telemetry reception. The green LED blinks on successful packet reception, and the red LED blinks when a packet with an invalid checksum is received.

  • The SPI driver used in both TeleDongle v3 and TeleGPS has been rewritten to avoid locking up under heavy CPU load. If you've got a TeleGPS board, you'll want to reflash with new firmware.

AltosUI and TeleGPS applications

A few minor new features are in this release

  • AltosUI can now compute and display tilt angle when graphing eeprom log data from TeleMega and EasyMega.

  • The AltosUI tool window is shown when starting with a data file. This way, when you double-click on a file in the file manager, you'll get the whole AltosUI interface, rather than just the graphing window.

  • At the end of replaying an old log file, stick 'done' in the Age field so you can tell the recording is over.

Bug Fixes

There are a bunch of minor bug fixes, including the usual collection of attempts to make stuff behave better on Windows platforms.

  • Use a different Windows API to discover USB device ids. This works better on my new HP Windows 7 machine. Maybe it will work better for other people too?

  • Look in more places in the Windows registry to try and find the installed Java version. It appears that the default Java download from Oracle is a 32-bit version? In any case, that version sticks its install information in a different spot in the registry.

  • Fix file associations on Windows when Java isn't installed in the system root.

  • Make 'Scan Channels' work better with new AltOS firmware which only reports device configuration information once ever five seconds.

February 08, 2015 07:57 AM

February 05, 2015

Richard Hughes, ColorHug

Ambient Light Sensors

An ambient light sensor is a little light-to-frequency chip that you’ve certainly got in your tablet, most probably in your phone and you might even have one in your laptop if you’re lucky. Ambient light sensors let us change the panel brightness in small ways so that you can still see your screen when it’s sunny outside, but we can dim it down when the ambient room light is lower to save power. Lots of power.

There is a chicken and egg problem here. Not many laptops have ambient light sensors; some do, but driver support is spotty and they might not work, or work but return values with some unknown absolute scale. As hardware support is so bad, we’ve not got any software that actually uses the ALS hardware effectively, and so most ALS hardware goes unused. Most people don’t actually have any kind of ALS at all, even on high-end models like Thinkpads

So, what do we do? I spent a bit of time over the last few weeks designing a small OpenHardware USB device that acts as a ALS sensor. It’s basically a ColorHug1 with a much less powerful processor, but speaking the same protocol so all the firmware update and test tools just work out of the box. It sleeps between readings too, so only consumes a tiiiiny amount of power. I figure that with hardware that we know works out of the box, we can get developers working on (and testing!) the software integration without spending hours and hours compiling kernels and looking at DSDTs. I was planning to send out devices for free to GNOME developers wanting to hack on ALS stuff with me, and sell the devices for perhaps $20 to everyone else just to cover costs.

pcb

The device would be a small PCB, 12x22mm in size which would be left in a spare USB slot. It only sticks out about 9mm from the edge of the laptop as most of the PCB actually gets pushed into the USB slot. It’s obviously non-ideal, and non-sexy, but I really think this is the way to break the chicken/egg problem we have with ALS sensors. It obviously costs money to make a device like this, and the smallest batch possible is about 60 – so before I spend any more of my spare money/time on this, is anyone actually interested in saving tons of power using an ALS sensor and dimming the display? Comment here or email me if you’re interested. Thanks.

by hughsie at February 05, 2015 04:44 PM

Andrew Zonenberg, Silicon Exposed

How to lose my business permanently

This post is a bit different from my usual ones in that it discusses the business side of the semiconductor industry, not the technical side. The issue has been getting more and more problematic lately so I figured I'd write up a few quick thoughts on it.

Let's suppose you're a large semiconductor company who is currently making a large amount of money selling chips to a couple of major customers. You've decided that your business is too big and you have no desire to get new customers, now or in the future. In fact, you don't even want these companies to use your products in new designs. What are some ways you can get rid of these pesky engineers trying to throw money at you?
  1. Make your parts hard to find. Ask major distributors like Digi-Key and AVnet to discontinue stocking them.
  2. If someone does manage to find an authorized sales partner, pester them with questions even if they're just looking for a budgetary price quote for a feasibility study. Ask for a project name, description, business plan, names of the team members, color of the soldermask, logo, and anything else you can think of. If it looks like an initial proof of concept that the customer isn't yet confident will become a high-volume product, or a one-off test fixture/lab tool, badger them by asking about annual sales volume and volume ramp-up dates until they lose interest and buy from a competitor.
  3. Just in case anyone actually succeeds in buying your part, make it useless to them. Keep the datasheet locked up in a steel vault in your corporate headquarters. Promise would-be customers that you'll let them see it if they sign away their firstborn son and sacrifice a golden lamb on an altar made of FPGAs, but hide the actual NDA contract behind so many redirect pages and broken links that nobody can actually sign it, much less see the actual datasheet. Bonus points if your chip is something commodity like a gigabit Ethernet PHY that has nothing even remotely sensitive in the datasheet.
If you follow these rules properly, congratulations! I'll do my part to further your goals by making sure you will never get design wins in any projects I'm involved in, especially high-volume ones for large companies. Your shareholders will be overjoyed.

by Andrew Zonenberg (noreply@blogger.com) at February 05, 2015 01:54 AM

February 02, 2015

ZeptoBARS

Reverse-engineering of KR580VM80A / i8080 is complete!

We are glad to announce that reverse engineering of KR580VM80A (the most popular CPU in the exUSSR, Intel 8080-compatible) is finally complete. Insane engineer Vslav (1801ВМ1@gmail.com) recovered full schematic in a very short time. After we got annotation and sorted out license (CC-BY-3.0) - it is available for everyone to enjoy.

It appeared that it had exactly 4758 transistors (contrary to rumors of 6000 or 4500).

Layout of KR580VM80A is quite similar though not identical to i8080, but there were no differing (vs i8080) opcodes identified.

Verilog model of KR580VM80A passed tough compatibility test both in simulation and as FPGA replacing actual KR580VM80A in "Specialist" computer.

Download links: Main verilog, Schematic, Full package.

Die annotation:

February 02, 2015 08:38 AM

NXP 74AHC00 : Weekend die-shot

What is the simplest possible microchip? Probably it's 7400 - quad 2-input NAND gate. We made a die shot of NXP's 74AHC00 (AHC means "fast" CMOS). This is a nice example that 'old' tech nodes (1µm and older) are still in use. Also, note how many spare via are there.

Die size - 944x854 µm.



Update 02.02.2015: We redid this chip with better quality. Original photo (September 2, 2012). Looking at the quality difference gives me a warm feeling, 2.5 years well spent...

February 02, 2015 08:17 AM

January 31, 2015

Bunnie Studios

Name that Ware, January 2015

The Ware for January 2015 is below.

“I love capacitor”

but why?

Been in Shenzhen the past two weeks, trying to beat Chinese New Year deadlines, improve my Chinese, and learn more about manufacturing and supply chains. So far, so good. Will have more updates soon!

by bunnie at January 31, 2015 10:53 AM

Winner, Name that Ware December 2014

The Ware for December 2014 is a Molecular Devices unity-gain headstage. It features an ultra-high impedance and low noise to allow the measurement of very tiny currents. I’d say Hugo had the closest answer of them all, congrats and email me for your prize!

by bunnie at January 31, 2015 10:49 AM

January 29, 2015

Free Electrons

Embedded Linux Conference schedule announced, several talks from Free Electrons

The schedule for the upcoming Embedded Linux Conference, which takes place on March 23-25 in San Jose, has been announced and is available publicly at http://elcabs2015.sched.org/, together with the Android Builders Summit schedule. As usual, there are lots of talks that look very interesting, so we can expect a very useful conference once again.

ELC 2015

This time around, there will be three talks given by Free Electrons engineers:

So, book your tickets, and join us for the Embedded Linux Conference at the end of March!

by Thomas Petazzoni at January 29, 2015 09:49 AM

January 28, 2015

Richard Hughes, ColorHug

Detecting fake flash

I’ve been using F3 to check my flash drives, and this is how I discovered my drives were counterfeit. It seems to me this kind of feature needs to be built inside gnome-multi-writer itself to avoid sending fake flash out to customers. Last night I wrote a simple tool called gnome-multi-writer-probe which does the following few things:

* Reads the existing data from the drive in 32kb chunks every 32Mbish into RAM
* Writes random blocks of 32kb every 32MBish, and also stores in RAM
* Resets the drive
* Reads all the 32k blocks from slightly different addresses and sizes and compares them to the random data in RAM
* Writes all the saved data back to the drive.

I only takes a few seconds on most drives. It also tries to be paranoid, and saves the data back to the drive the best it can when it encounters an error. That said, please don’t use this tool on any drives that have important data on them; assume you’ll have to reformat them after using this tool. Also, it’s probably a really good idea to unmount any drives before you try this.

If you’ve got access to gnome-multi-writer from git (either from jhbuild, or from my repo) then please could you try this:

sudo gnome-multi-writer-probe /dev/sdX

Where sdX is the USB drive you want to test. I’d be interested of the output, and especially interested if you have any fake flash media you can test this with. Either leave a comment here, grab me on IRC or send me an email. Thanks.

by hughsie at January 28, 2015 02:01 PM

Free Electrons

Free Electrons at FOSDEM 2015

FOSDEM BannerFor many open-source developers based in Europe, the FOSDEM is probably the most useful, interesting and exciting conference. Once again this year, several Free Electrons engineers will attend the conference:

  • Maxime Ripard, mainly involved in Allwinner related kernel development, as well as more recently OpenWRT support for Marvell platforms
  • Antoine Ténart, involved in Marvell Berlin related kernel development, and one of the developers of our Yocto Project and OpenEmbedded training course
  • Alexandre Belloni, involved in Atmel processors related kernel development, and also one of our Yocto expert.
  • Thomas Petazzoni, involved in Marvell EBU processors related kernel development, and doing a lot of Buildroot contributions.

If you are attending, and want to know more about Free Electrons, or discuss career or project opportunities, do not hesitate to contact us prior to the conference. Many of us will probably attend a significant number of talks from the Embedded track, so it should be easy to find us.

Last but not least, Alexandre Belloni will be giving a talk about Starting with the Yocto Project, which will take place on Sunday, at 3 PM in room Lameere.

Finally, Thomas Petazzoni has organized and will participate to the Buildroot Developers Meeting organized right after FOSDEM, and sponsored by Google and Mind.

by Thomas Petazzoni at January 28, 2015 08:48 AM

January 27, 2015

Richard Hughes, ColorHug

Scammers at promo-newa.com

tl;dr Don’t use promo-newa.com, they are scammers that sell fake flash.

Longer version: For the ColorHug project we buy a lot of the custom parts direct from China at a fraction of the price available to us in the UK, even with import tax considered. It would be impossible to produce such a low cost device and still make enough money to make it worth giving up our evenings and weekends. This often means sending thousands of dollars to sketchy-looking companies willing to take on small (to them!) custom orders of a few thousand parts.

So far we’ve been very lucky, until last week. I ordered 1000 customized 1GB flash drives to use as a LiveUSB image rather than using a LiveCD. I checked out the company as usual, and ordered a sample. The sample came back good quality, with 1GB of fast flash. Payment in full was sent, which isn’t unusual for my other suppliers in China.

Fast forward a few weeks. 1000 USB drives arrived, which look great. Great, until you start using them with GNOME MultiWriter, which kept throwing validation warnings. Using the awesome F3 and a few remove-insert cylces later, the f3probe tool told me the flash chip was fake, reporting the capacity to be 1GB, when it was actually 96Mb looped around 10 times.

Taking the drives apart you could also see the chip itself was different from the sample, and the plastic molding and metal retaining tray was a lower quality. I contacted the seller, who said he would speak to the factory later that day. The seller got back to me today, and told me that the factory has produced “B quality drives” and basically, that I got what I paid for. For another 1600USD they would send me the 1GB ICs, which I would have to switch in the USB units. Fool me once, shame on you; fool me twice, shame on me.

I suppose people can use the tiny flash drives to get the .icc profile off the LiveCD image, which was always a stumbling block for some people, but basically the drives are worthless to me as LiveUSB devices. I’m still undecided whether to include them in the ColorHug box; i.e. is a free 96Mb drive better than them all going into landfill?

As this is China, I understand all my money is gone. The company listing is gone from Alibaba, so there’s not a lot I can do there. So other people can hopefully avoid this same mistake, I’ve listed all the details here, which hopefully will become googleable:

Promo-Newa Electronic Limited(Shenzhen)
Wei and Ping Group Limited(Hongkong)  

Office: Building A, HuaQiang Garden, North HuaQiang Road, Futian district, Shenzhen China, 0755-3631 4600
Factory: Building 4, DengXinKeng Industrial Zone, JiHua Road,LongGang District, Shenzhen, China
Registered Address: 15/B—15/F Cheuk Nang Plaza 250 Hennessy Road, HongKong
Email: sales@promo-newa.com
Skype: promonewa

by hughsie at January 27, 2015 03:11 PM

Free Electrons

Meet us at Embedded World 2015!

Atmel booth at Embedded World 2014Free Electrons will be present at Embedded World 2015 in Nüremberg, Germany on February 24-26. We will be present on the Atmel Corporation booth (4A-220) to demonstrate our Atmel-related developments and offerings.

Four people from Free Electrons will be present: Michael Opdenacker (CEO), Thomas Petazzoni (CTO), Anja Roubin (training operations) and Alexandre Belloni (embedded Linux engineer).

Do not hesitate to get in touch with us prior to the event if you would like to schedule a meeting to discuss business, project or career opportunities.

If you are interested in our training services, we will have very special discount vouchers for people who visit us at Embedded World.

You will also be able to ask us for free advise during the trade show. We have vast experience on embedded Linux and its kernel, and we will be most happy to give you ideas and pointers to resources that should be useful for your projects.

by Thomas Petazzoni at January 27, 2015 08:54 AM

2015 Q1 newsletter

This article was published on our quarterly newsletter.

The Free Electrons team wishes you a Happy New Year for 2015, with plenty of optimism and energy!

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

Kernel contributions

We continue to work significantly on support for various ARM processors in the Linux kernel. Our contributions to the latest kernel releases:

  • 147 patches from Free Electrons merged in Linux 3.17, making Free Electrons the 14th contributing company for this release by number of patches. See our blog post about this release.
  • 155 patches from Free Electrons merged in Linux 3.18, making Free Electrons the 14th contributing company. See our blog post for more details.
  • For the upcoming 3.19 release, we already have 196 patches merged.

One of the highlights was that we added support for the Atmel SAMA5D4 SoC to the Linux kernel even before the new chip was announced by Atmel! That’s a very positive sign for customers when an SoC is supported in the mainline Linux kernel sources right at product launch, instead of having to wait for months or years before the community developers can catch up.

Note that we also added Atmel SAMA5D3 SoC support to Xenomai, a hard real-time extension for the Linux kernel. Thanks to this, the Atmel SAMA5D3 Xplained board can now run with the 2.6.x release of Xenomai.

Besides those highlights, most of our kernel contributions were as usual centered around support for specific families of ARM processors: CPUs from Marvell EBU and Marvell Berlin, from Atmel and from Allwinner. We added a new network driver for some Marvell EBU processors, added SMP support for Marvell Berlin processors, added a DMA controller driver for Allwinner processors, and did a lot of maintenance work to support these processors in the mainline kernel.

Buildroot contributions

Our involvement into the Buildroot project, a popular embedded Linux build system, is going on. Our engineer Thomas Petazzoni contributed 136 patches to the 2014.11 release, making him the second contributor by number of patches. Thomas is also taking care of the maintenance of the project on a more regular basis, reviewing and merging patches from contributors.

OpenWRT contributions

We have recently started contributing to the OpenWRT project: improve the kernel support to use defconfig, introduce a notion of board to support different NAND configurations for each platform. We will soon to be pushing support for the Marvell Armada 385 platform, and improved support for the Marvell Armada 370 and XP platforms.

Recent projects

Besides our publicly visible kernel contributions, we do also work on customer-specific projects. Among the latest projects we have done:

  • Develop a complete Board Support Package for a custom TI AM335x based platform: U-Boot porting, Linux kernel porting, and development of a Yocto-generated system. Qt5 and OpenGL are used for the graphical application, a fairly complex audio setup had to be supported, and many traditional interfaces as well (USB Host and Device, CAN, display, etc.)
  • Develop a Board Support Package for a custom Marvell Armada 375 based platform for a telephony system. Not only did we port a Linux kernel on this platform, but we also wrote several DAHDI drivers to interface the telephony hardware of the platform with Asterisk.
  • NAND and UBI stress-testing for a customer-specific Freescale i.MX28 based platform. We improved the NAND controller driver, added a new MTD tool to generate bitflips, and did some long term power-cut stress-testing of the UBIFS setup to ensure the reliability of the platform. See our kernel driver improvements and the new nandflipbits tool.
  • Adapt an existing ADC driver for a customer-specific platform to the modern Industrial Input Output (IIO) subsystem of the kernel.

Conferences: FOSDEM, Embedded World and Embedded Linux Conference

Several Free Electrons engineers will participate to the FOSDEM conference, taking place on January 30 and February 1 in Brussels. In addition, Thomas Petazzoni will be participating to the Buildroot Developers Meeting that takes place right after FOSDEM in the Google offices in Brussels.

Free Electrons will participate to the Embedded World trade show on February 24-26 in Nuremberg, Germany. We will be present at Atmel’s booth and visiting exhibitor booths too. For people in Europe, this will be a good opportunity to ask your questions about our embedded Linux training and engineering services. In particular, you will be able meet our engineers Alexandre Belloni, Thomas Petazzoni (CTO), Michael Opdenacker (CEO) and Anja Roubin as well, the new person in charge of our training services.

This year again, most of the Free Electrons engineering team (7 engineers) will participate to the 2015 edition of the Embedded Linux Conference on March 23-25 in San Jose, California. We submitted several talk proposals, but our presence won’t depend on the number of talks that are eventually accepted. Participating to this conference, and to its European edition in the fall too, is very important for us to make sure we do not miss any of the interesting developments in the technical community, and above all to strengthen our ties with the community developers. This helps us to be good technical trainers with valuable experience and information to share. The strong relationships with other community developers (and in particular with project maintainers) also help us when our customers contract us to add hardware support or features to official versions of community projects such as the Linux kernel.

Free technical documentation resources

Since the latest edition of this newsletter, we started running our new Yocto Project and OpenEmbedded course, and we released all training materials for this course. As usual, such materials are meant to be used by people learning by themselves too. All you have to do is get your hands on a Beaglebone Black board, read the slides and try to do the labs!

Our engineer Maxime Ripard also contributed documentation about the DMAEngine subsystem in the Linux kernel.

Upcoming training sessions – Now in Paris too!

The news is that we will run new public sessions in Paris, in addition to the ones we usually organize in Toulouse, Avignon and Lyon in France. We are starting with our embedded Linux and our Yocto courses, but other topics will follow too.

So, here are our next session dates:

See sessions and dates for more details. Of course, we can also deliver our training courses at your location, anywhere in the world. Feel free to contact us for a quote.

If you are interested in more frequent news about Free Electrons, you can follow us on Twitter, Google+ and LinkedIn.

by Michael Opdenacker at January 27, 2015 05:35 AM

DMAEngine Documentation: Work (finally) in Progress

While developping a DMA controller driver for the Allwinner A31 SoCs (that eventually got merged in the 3.17 kernel), I’ve realised how under-documented the DMAEngine kernel subsystem was, especially for a newcomer like I was.

After discussing this with a few other kernel developers in the same situation, I finally started to work on such a documentation during the summer, and ended up submitting it at the end of July. As you might expect, it triggered a lot of questions, comments and discussions that enhanced a lot the documentation itself but also pointed out some inconsistencies in the API, obscure areas or just enhancements.

This also triggered an effort to clean up these areas, and hopefully, a lot more will follow, allowing to eventually clean up the framework as a whole.

And the good thing is that this documentation has been merged by the DMAEngine maintainer and is visible in linux-next, feel free to read it, and enhance it!

by Maxime Ripard at January 27, 2015 05:32 AM

January 23, 2015

ZeptoBARS

MC34063 : Weekend die-shot

MC34063 is by far the most widespread DC-DC switching regulator.



Update 23.01.2015: We've returned to this chip while testing new optical and etching setup. Here is it again with metalization stripped. Original article was published 25.11.2012.


January 23, 2015 03:12 PM

January 21, 2015

Richard Hughes, ColorHug

Plugable USB Hubs

Joshua from Plugable sent me 4 different USB hubs this week so they could be added as quirks to gnome-multi-writer. If you’re going to be writing lots of USB drives, the Plugable USB3 hubs now work really well. I’ve got a feeling that inserting and removing the drive is going to be slower than the actual writing and verifying now…

by hughsie at January 21, 2015 08:30 PM

Moving update information from the distribution to upstream

I’ve been talking to various people about the update descriptions we show to the user. Without exception, the messages we show to end users are really bad. For example, the overly-complex-but-not-actually-useful:

Screenshot from 2015-01-21 10:56:34

Or, the even more-to-the-point:

Update to 3.15.4

I’m guilty of both myself. Why is this? Typically this text is written an over-worked and under-paid packager doing updates to many applications and packages. Sometimes the packager might be the upstream maintainer, or at least involved in the project, but many times it’s just some random person that got fingered to maintain a particular package. This doesn’t make an awesome person to write beautiful prose and text that thousands of end users are going to read. It also doesn’t make sense to write the same beautiful prose again and again for every distribution out there.

So, what do we need? We need a person who probably wrote the code, or at least signed it off, who cares about the project and cares about the user experience. i.e. the upstream maintainer.

What I’m proposing is that we ask upstream maintainers to write the release information in a way that can be shown in the software center. NEWS files are not stanardized, and you don’t typically have a NEWS file for each application in your upstream tarball, so we need something else.

Suprise suprise, it’s AppStream to the rescue. AppStream has a <release> object that fits the bill almost completely; you can put upstream version information and long (optionally translated) formatted descriptions.

Of course, you don’t want to write both NEWS and the various appdata files at release time, as that just increased the workload of the overly-busy upstream maintainer. In this case we can use appstream-util appdata-to-news in the buildsystem and generate the former from the latter automatically. We’re outputting markdown for the NEWS file, which seems to be a fairly good approximation of what NEWS files actually look like at least for GNOME.

For a real-world example, see the GNOME MultiWriter example commit that uses this.

There are several problems with this approach. One is that the translators might have to translate lots more text; and the obvious solution to that seems to be to only mark strings to be translated for stable versions. Alas, projects like GNOME don’t allow any new strings in stable versions, so we’ll either have to come up with an except for release notes ammendment to that, or just say that all the release notes are only ever available in C locale.

The huge thing to take away from this blog, if you are intending to use this new feature is that update descriptions have to be understandable by end users. Various bug fixes is not helpful, but Fixes a crash when adding a joystick is. End users neither care or understand Use libgusb rather than libusbx and technical details that do not affect the UI or UX of the application should be omitted.

This doesn’t work for distribution releases, e.g. 3.14.1-1 to 3.14.1-2, but typically these are not huge changes that we need to show so prominently to the user.

I’m also writing a news-to-appdata.py script, so if anyone wants to take the plunge on an existing project it might be good to wait for that unless you like lots of copy and pasting.

Comments, as always, welcome.

by hughsie at January 21, 2015 11:00 AM

Andrew Zonenberg, Silicon Exposed

TDR updates

A few months ago, I wrote about a project I had been thinking of for a while but not had time to work on: a time-domain reflectometer (TDR) for testing twisted pair Ethernet cables.

TDR background


The basic theory of operation is simple: Send a pulse down a transmission line and measure the reflected voltage over time to get a plot of impedance discontinuities over time. Unfortunately, doing this with sufficient temporal resolution (sub-nanosecond) requires extremely high analog sampling rates, and GHz A/D converters are (to say the least) not cheap: the least expensive 1 GSA/s ADC on Digi-Key is the HMCAD1520, which sells for $120 each at the time of this writing. Higher sampling rates cost even more, the 1.5 GSa/s ADC081500CIYB is listed at $347.

One possible architecture would consist of a pre-amplifier for each channel, a 4:1 RF mux, and a single high-speed ADC sampled by an FPGA. This would work, but seemed quite expensive and I wanted to explore lower-cost options.

ADC architecture


After thinking about the problem for a while, I realized that the single most expensive component in a classical TDR was probably the ADC - but there was no easy way to make it cheaper. What if I could eliminate the ADC entirely?

I drew inspiration from the successive-approximation-register (SAR) ADC architecture, which essentially converts a DAC into an ADC by binary searching. The basic operating algorithm is as follows:
  • For each point T in time
    • vstart = 0
    • vend = Vref
    • Set DAC to (Vstart + Vend) / 2
    • Compare Vin against Vdac
    • If Vin > Vdac
      • Set current bit of sample to 1
      • Set Vstart to Vdac, update ADC, repeat
    • else
      • Set current bit of sample to 0
      • Set Vend to Vdac, update ADC, repeat
The problem with SAR for high speeds is that N-bit analog resolution at M samples per second requires a DAC that can run at O(M log N) samples per second - hardly an improvement!

In order to work around this problem, I began to think about ways to represent the data generated by a SAR ADC. I ended up modeling a simplified SAR ADC which performed a linear, rather than binary, search. We can represent the intermediate data as a matrix of 2^N rows by M columns, one for each of M data points.

The sampling algorithm for this simplified ADC works as follows:
  • For each point T in time 
    • Set DAC to 0
    • Compare Vin against Vdac
    • If Vin > Vdac
      • Set column[Vdac] to 1
      • Increment Vdac
      • Repeat comparison
    • Otherwise stop and capture the next sample
Once we have this matrix, we can simply sum the number of 1s in each column to calculate the corresponding sample value.

While this approach will clearly work, it is exponentially slower than the conventional SAR ADC since it requires 2^N samples instead, instead of N, for N-bit precision. So why is it useful?

Now consider what happens if we acquire the data from a transposed version of the same matrix:
  • For each Vdac from 0 to Vref
    • For each point T in time
      • Compare Vin against Vdac
      • If Vin > Vdac
        • Set row Vin of column T to 1
    • Increment Vref
    • Go back in time and loop over the signal again
This version clearly captures the same data, since matrix[T][V] is set to true iff sample T is less than V. We simply switch the inner and outer loops.

It also has a very interesting property for cost optimization: Since it only updates the DAC after sampling the entire signal, we can now use a much slower (and cheaper) DAC than with a conventional SAR. In addition, the comparator can now update at the sampling frequency instead of 2^N times the sampling frequency.

There's just one problem: It requires time travel! Why are we wasting our time analyzing a circuit that can't actually be built?

Well, as it turns out we can solve this problem too - with "parallel universes". Since the impedance of the cable is (hopefully) fairly constant over time, if we send multiple pulses they should return identical reflection waveforms. We can thus send out a pulse, test one candidate Vdac value against this waveform, then increment Vdac and repeat.

The end result is that with a cheap SPI DAC, a high-speed comparator, and an FPGA with a high-speed digital input we can digitize a repetitive signal to arbitrary analog precision, with sampling rate limited only by comparator bandwidth and FPGA input buffer performance!

Pulse generation

The first step in any TDR, of course, is to generate the pulse.

I spent a while looking over FPGAs and ended up deciding on the Xilinx Kintex-7 series, specifically the XC7K70T. The -1 speed grade can do 1.25 Gbps LVDS in the high-performance I/O banks (matching the -2 and -3 speed Artix-7 devices) and the higher speed grades can go up to 1.6 Gbps.

The pulse is generated by using the OSERDES of the FPGA to produce a single-cycle LVDS 1 followed by a long series of 0s. The resulting LVDS pulse is fed into a Micrel SY58603U LVDS-to-CML buffer. This slightly increases the amplitude of the output pulse and sharpens the rise time up to 80ps.

The resulting pulse is then sent through the RJ45 connector onto the cable being tested.

Output buffer

Input preamplifier

The reflected signal coming off the differential pair is AC coupled with a pair of capacitors to prevent bus fights between the (unequal) common-mode voltages of the output buffer and the preamplifier. It is then fed into a LMH6881 programmable-gain preamplifier.

This is by far the most pricey analog component I've used in a design: nearly $10 for a single amplifier. But it's a very nice amplifier (made on a SiGe BiCMOS process)- very high linearity, 2.4 GHz bandwidth, and gain from 6 to 26 dB programmable over SPI in 0.25 dB steps.

Input preamplifier
The optional external terminator (R25) is intended to damp out any reflections coming off of the preamplifier if they present a problem; during the initial assembly I plan to leave it unpopulated. Since this is my first high-speed mixed signal design I'm trying to make it easy to tweak if I screwed up somehow :)

The output of the preamplifier is a differential signal with 2.5V common mode offset.

Differential to single-ended conversion

The next step is to convert the differential voltage into a single-ended voltage that we can feed into the comparator. I use an AD8045 unity gain voltage feedback amplifier for this, configured to compute CH1_VDIFF = (CH1_BUF_P - CH1_BUF_N)  + 2.5V.

Digitization

The single-ended voltage is compared against the DAC output (AFE_VREF) using one half of an LMH7322 dual comparator.

The output supply of the comparator is driven by a 2.5V supply to produce LVDS-compatible differential output voltage levels.

PCB layout

The board was laid out in KiCAD using the new push-and-shove router. All of the differential pairs were manually length-matched to 0.1mm or better.

The upper left corner of the board contains four copies of the AFE. The AD8045s are on the underside of the board because the pinout made routing easier this way. Hopefully the impedance discontinuities from the vias won't matter at these signal speeds...

AFE layout, front side
AFE layout, back side
The rest of the board isn't nearly as complex: the lower left has a second RJ45 connector and a RGMII PHY for interfacing to the host PC, the power supply is at the upper right, and the FPGA is bottom center.

The power supply is divided into two regions, digital and analog. The digital supply is on the far right side of the board, safely isolated from the AFE. It uses an LTC3374 to generate an 1.0V 4A rail for the FPGA core, a 1.2V 2A rail for the FPGA transceivers and Ethernet PHY, a 1.8V 1A rail for digital I/O, and a 2.5V rail for the CML buffers and Ethernet analog logic.

The analog supply was fairly close to the AFE so I put a guard ring around it just to be safe. It consists of a LTC3122 boost converter to push the 5V nominal input voltage up to 6V, followed by a 5V LDO to give a nice clean analog rail. I ran the output of the LDO through a pi filter just to be extra safe.

The TDR subsystem didn't use any of the four 6.6 Gbps GTX serial transceivers on the FPGA because they are designed to recover their clock from the incoming signal and don't seem to support use of an external reference clock. It seemed a shame to waste them, though, so I broke them (as well as 20 0.95 Gbps LVDS channels) out to a Samtec Q-strip header for use as high-speed GPIO.

Without further ado, here's the full layout. I could have made the board quite a bit smaller in the vertical axis but I needed to keep a constant 100mm high so it would fit in the card guides on my Eurocard rack.

The board is at fabs for quotes now and I'll make another post once the boards come back.

Layer 1
Layer 2 (ground)
Layer 3 (power)
Layer 4, flipped to make text readable

by Andrew Zonenberg (noreply@blogger.com) at January 21, 2015 02:07 AM

January 16, 2015

Andrew Zonenberg, Silicon Exposed

Electronic Privacy: A Realist's Perspective

    Note: I originally wrote this in a Facebook note in March 2012, long before any of the recent leaks. I figured it'd be of interest to a wider audience so I'm re-posting it here.
    There's been a lot of hullabaloo lately about Google's new privacy policy etc so I decided to write up a little article describing my personal opinions on the subject.
    Note that I'm describing defensive policies which may be a bit more cynical than most people's, and not considering relevant laws or privacy policies at all. The assumption being made here is that if it's possible, and someone wants it to happen enough, they will make it happen regardless of whether it's legal.

    RULE 1: If it's on someone else's server, and not encrypted, it's public information.
    Rationale: Given the ridiculous number of data breaches we've had lately it's safe to say that any sufficiently motivated and funded person / agency could break into just about any company storing data they're interested in. On top of this, in many countries government agencies have a history of sending companies subpoenas asking for data they're interested in, which is typically forked over with little or no question.
    This goes for anything from your Facebook profile to medical/financial records to email.
    RULE 1.1: Privacy settings/policies keep honest people honest.
    Rationale: Hackers and government agencies, especially foreign ones, don't have to play by the rules. Services have bugs. Always assume that your privacy settings are wide open and set them tighter only as an additional (small) layer of defense.
    RULE 2: If it's encrypted, but you don't control the key completely, it's public information.
    Rationale: Encryption is only as good as your key management. If somebody else has the key they're a potential point of failure. Want to bet $COMPANY's key management isn't as good as yours? Also, if $COMPANY can be forced/tricked/hacked into turning over the key without your knowledge, the data is as good as public anyway.
    RULE 3: If someone can talk to it, they can root it.
    Rationale: It's pretty much impossible to say "there are no undiscovered bugs in this code" so it's safest to assume the worst... there is a bug in your operating system / installed software and anyone with enough time or money can find or buy an 0day. Want to bet there are NO security-related bugs in the code your box is running? Me neither. If your system isn't airgapped assume it could have been pwned.
    RULE 4: If it goes over an RF link and isn't end-to-end encrypted, it's public information.
    Rationale: This includes wifi (even with most grades of WEP/WPA encryption), cellular links, and everything else of that nature. Sure, the carrier may be encrypting your SMS/voice calls with some proprietary scheme of uncertain security, but they have the key so Rule 2 applies.
    RULE 5: If you have your phone with you, your whereabouts and anything you say is public information.
    Rationale: This can be derived from Rule 3. Your phone is just a computer and third parties can communicate with it. Since it includes a microphone and GPS, assume the device has been rooted and they're logging to $BADGUY on a 24/7 basis.
    RULE 6: All available data about someone/something can and will be correlated.
    Rationale: If two points of data can be identified as related, someone will figure out a way to combine them. Examples include search history (public according to Rule 1), identical usernames/emails/passwords used on different services, and public records. If someone knows that JoeSchmoe1234 said $FOO on GamingForum.com and someone else called JoeSchmoe1234 said $BAR on HackingForum.com it's a pretty safe bet both comments came from the same person who's interested in gaming and hacking.

by Andrew Zonenberg (noreply@blogger.com) at January 16, 2015 09:32 PM

Threat modeling for FPGA software backdoors


I've been interested in the security of compilers and related toolchains ever since I first read about Ken Thompson's compiler backdoor many years ago. In a nutshell, this famous backdoor does two things:

  • Whenever the backdoored C compiler compiles the "login" command, it adds a second code path that accepts a hard-coded default password in addition to the user's actual password
  • Whenever the backdoored C compiler compiles the unmodified source code of itself, it adds the backdoor to the resulting binary.
The end result is a compiler that looks fine at the source level, silently backdoors a critical system file at compilation time, and reproduces itself.

Recently, there has also been a lot of concern over backdoors in integrated circuits (either added at the source code level by a malicious employee, or at the netlist/layout level by a third-party fab). DARPA even has a program dedicated to figuring out ways of eliminating or detecting such backdoors. A 2010 paper stemming from the CSAW Embedded Systems Challenge presents a detailed taxonomy of such hardware Trojans.

As far as I can tell, the majority of research into hardware Trojans has been focused on detecting them, assuming the adversary has managed to backdoor the design in some way that provides him with a tactical or strategic advantage. I have had difficulty finding detailed threat modeling research quantifying the capability of the adversary under particular scenarios.

When we turn our attention to FPGAs, things quickly become even more interesting. There are several major differences between FPGAs and ASICs from a security perspective which may grant the adversary greater or lesser capability than with an ASIC.

Attacks at the IC fab


The function of an ASIC is largely defined at fab time (except for RAM-based firmware) while FPGAs are extremely flexible. When trying to backdoor FPGA silicon the adversary has no idea what product(s) the chip will eventually make it into. They don't even know which pins on the die will be used as inputs and which as outputs.

I suspect that this places substantial bounds on the capability of an attacker "Malfab" targeting FPGA silicon at the fab (or pre-fab RTL/layout) level since the actual RTL being targeted does not even exist yet. To start, we consider a generic FPGA without any hard IP blocks:
  • Malfab does not know which flipflops/SRAM/LUTs will eventually contain sensitive data, nor what format this data may take.
  • Malfab does not know which I/O pins may be connected to an external communications interface useful for command-and-control.
As a result, his only option is to create an extremely generic backdoor. At this level, the only thing that makes sense is to connect all I/O pins (perhaps through scan logic) to a central malware logic block which provides the ability to read (and possibly modify) all state in the device. This most likely would require two major subsystems:
  • A detector, which searches I/Os for a magic sync sequence
  • A connection from that detector to the FPGA's internal configuration access port (ICAP), used for partial reconfiguration and readback.
The design of this protocol would be very challenging since the adversary does not know anything about the external interfaces the pin may be connected to. The FPGA could be in a PLC or similar device whose only external contact is RS-232 serial on a single input pin. Perhaps it is in a network router/switch using RGMII (4-bit parallel with double data rate signalling).

I am not aware of any published work on the feasibility of such a backdoor however I am skeptical that a sufficiently generic Trojan could be made simple enough to evade even casual reverse engineering of the I/O circuitry, and fast enough to not seriously cripple performance of the device.

Unfortunately for our defender Alice, modern FPGAs often contain hard IP blocks such as SERDES and RAM controllers. These present a far more attractive target to Malfab as their functionality is largely known in advance.

It is not hard to imagine, for example, a malicious patch to the RAM controller block which searches each byte group for a magic sync sequence written to consecutive addresses, then executes commands from the next few bytes. As long as Malfab is able to cause the target's system to write data of his choice to consecutive RAM addresses (perhaps by sending it as the payload of an Ethernet frame, which is then buffered in RAM) he can execute arbitrary commands on the backdoor engine. If one of these commands is "write data from SLICE_X37Y42.A5FF to RAM address 0xdeadbeef", and Malfab can predict the location of a transmit buffer of some sort, he now has the ability to exfiltrate arbitrary state from Alice's hardware.

I thus conjecture that the only feasible way to backdoor a modern FPGA at fab time is through hard IP. If we ensure that the JTAG interface (the one hard IP block whose use cannot be avoided) is not connected to attacker-controlled interfaces, use off-die SERDES, and use softcore RAM controllers on non-standard pins, it is unlikely that Malfab will be able to meaningfully affect the security of the resulting circuit.

Attacks on the toolchain

We now turn our attention to a second adversary, Maldev - the malicious development tool. Maldev works for the FPGA vendor, has compromised the source repository for their toolchain, has MITMed the download of the toolchain installer, or has penetrated Alice's network and patched the software on her computer.

Since FPGAs are inherently closed systems (more so than ASICs, in which multiple competing toolchains exist), Alice has no choice but to use the FPGA vendor's binary-blob toolchain. Although it is possible in theory for a dedicated team with sufficient time and budget to reverse engineer the FPGA and/or toolchain and create a trusted open-source development suite, I discount the possibility for the scope of this section since a fully trusted toolchain is presumably free of interesting backdoors ;)

Maldev has many capabilities lacking to Malfab since he can execute arbitrary code on Alice's computer. Assuming that Alice is (justifiably) paranoid about the provenance of her FPGA software and runs it on a dedicated machine in a DMZ (so that it cannot infect the remainder of her network), this is equivalent to having full access to her RTL and netlist at all stages of design.

If Alice gives her development workstation Internet access, Maldev now has the ability to upload her RTL source and/or netlist, modify it at will on his computer, and then push patches back. This is trivially equivalent to a full defeat of the entire system.

Things become more interesting when we cut off command-and-control access. This is a realistic scenario if Alice is a military/defense user doing development on a classified network with no Internet connection.

The simplest attack is for Maldev to store a list of source file hashes and patches in the compromised binary. While this is very limited (custom-developed code cannot be attacked at all), many design teams are likely to use a small set of stock communications IP such as the Xilinx Tri-Mode Ethernet MAC, so patching these may be sufficient to provide him with an attack vector on the target system. Looking for AXI interconnect IP provides Maldev with a topology map of the target SoC.

Another option is graph-based analytics on the netlist at various stages of synthesis. For example, by looking for a 32-bit register initialized to 0x67452301, which is in a strongly connected component with three other registers initialized to 0xefcdab89, 0x98badcfe, and 0x10325476, Maldev can say with a high probability that he has found an implementation of MD5 and located the state registers. By looking for a 128-bit comparator between these values and another 128-bit value, a hash match check has been found (and a backdoor may be inserted). Similar techniques may be used to look for other cryptography.

Conclusions

If FPGA development is done using silicon purchased before the start of the project, on an air-gapped machine, and without using any pre-made IP, then some bounds can clearly be placed on the adversary's capability.

I have not seen any formal threat modeling studies on this subject, although I haven't spent a ton of time looking for them due to research obligations. If anyone is aware of published work in this field I'm extremely interested.

by Andrew Zonenberg (noreply@blogger.com) at January 16, 2015 09:32 PM

Why Apple's iPhone encryption won't stop NSA (or any other intelligence agency)

Recent news headlines have made a big deal of Apple encrypting more of the storage on their handsets, and claiming to not have a key. Depending on who you ask this is either a huge win for privacy, or a massive blow to intelligence collection and law enforcement capabilities. I'm going to try avoiding expressing any opinions of government policy here and focus on the technical details of what is and is not possible - and why disk encryption isn't as much of a major game-changer as people seem to think.

Matthew Green at Johns Hopkins wrote a very nice article on the subject recently, but there are a few points I feel it's worth going into more detail on.

The general case here is that of two people, Alice and Bob, communicating with iPhones while a third party, Eve, attempts to discover something about their communications.

First off, the changes in iOS 8 are encrypting data on disk. Voice calls, SMS, and Internet packets still cross the carrier's network in cleartext. These companies are legally required (by CALEA in the United States, and similar laws in other countries) to provide a means for law enforcement or intelligence to access this data.

In addition, if Eve can get within radio range of Alice or Bob, she can record the conversation off the air. Although the radio links are normally encrypted, many of these cryptosystems are weak and can be defeated in a reasonable amount of time by cryptanalysis. Numerous methods are available for executing man-in-the-middle attacks between handsets and cell towers, which can further enhance Eve's interception capabilities.

Second, if Eve is able to communicate with Alice or Bob's phone directly (via Wi-Fi, SMS, MITM of the radio link, MITM further upstream on the Internet, physical access to the USB port, or using spearphishing techniques to convince them to view a suitably crafted e-mail or website) she may be able to use an 0day exploit to gain code execution on the handset and bypass any/all encryption by reading the cleartext out of RAM while the handset is unlocked. Although this does require that Eve have a staff of skilled hackers to find an 0day, or deep pockets to buy one, when dealing with a nation/state level adversary this is hardly unrealistic.

Although this does not provide Eve with the ability to exfiltrate the device  encryption key (UID) directly, this is unnecessary if cleartext can be read directly. This is a case of the general trend we've been seeing for a while - encryption is no longer the weakest link, so attackers figure out ways to get around it rather than smash through.

Third, in many cases the contents of SMS/voice are not even required. If the police wish to geolocate the phone of a kidnapping victim (or a suspect) then triangulation via cell towers and the phone's GPS, using the existing e911 infrastructure, may be sufficient. If intelligence is attempting to perform contact tracing from a known target to other entities who might be of interest, then the "who called who when" metadata is of much more value than the contents of the calls.

There is only one situation where disk encryption is potentially useful: if Alice or Bob's phone falls into Eve's hands while locked and she wishes to extract information from it. In this narrow case, disk encryption does make it substantially more difficult, or even impossible, for Eve to recover the cleartext of the encrypted data.

Unfortunately for Alice and Bob, a well-equipped attacker has several options here (which may vary depending on exactly how Apple's implementation works; many of the details are not public).

If the Secure Enclave code is able to read the UID key, then it may be possible to exfiltrate the key using software-based methods. This could potentially be done by finding a vulnerability in the Secure Enclave (as was previously done with the TrustZone kernel on Qualcomm Android devices to unlock the bootloader). In addition, if Eve works for an intelligence agency, she could potentially send an NSL to Apple demanding that they write firmware, or sign an agency-provided image, to dump the UID off a handset.

In the extreme case, it might even be possible for Eve to compromise Apple's network and exfiltrate the certificate used for signing Secure Enclave images. (There is precedent for this sort of attack - the authors of Stuxnet appear to have stolen a driver-signing certificate from Realtek.)

If Apple did their job properly, however, the UID is completely inaccessible to software and is locked up in some kind of on-die hardware security module (HSM). This means that even if Eve is able to execute arbitrary code on the device while it is locked, she must bruteforce the passcode on the device itself - a very slow and time-consuming process.

In this case, an attacker may still be able to execute an invasive physical attack. By depackaging the SoC, etching or polishing down to the polysilicon layer, and looking at the surface of the die with an electron microscope the fuse bits can be located and read directly off the surface of the silicon.

E-fuse bits on polysilicon layer of an IC (National Semiconductor DMPAL16R). Left side and bottom right fuses are blown, upper right is conducting. (Note that this is a ~800nm process, easily readable with an optical microscope. The Apple A7 is made on a 28nm process and would require an electron microscope to read.) Photo by John McMaster, CC-BY
Since the key is physically burned into the IC, once power is removed from the phone there's no practical way for any kind of self-destruct to erase it. Although this would require a reasonably well-equipped attacker, I'm pretty confident based on my previous experience that I could do it myself, with equipment available to me at school, if I had a couple of phones to destructively analyze and a few tens of thousands of dollars to spend on lab time. This is pocket change for an intelligence agency.

Once the UID is extracted, and the encrypted disk contents dumped from the flash chips, an offline bruteforce using GPUs, FPGAs, or ASICs could be used to recover the key in a fairly short time. Some very rough numbers I ran recently suggest that an 6-character upper/lowercase alphanumeric SHA-1 password could be bruteforced in around 25 milliseconds (1.2 trillion guesses per second) by a 2-rack, 2500-chip FPGA cluster costing less than $250,000. Luckily, the iPhone uses an iterated key-derivation function which is substantially slower.

The key derivation function used on the iPhone takes approximately 50 milliseconds on the iPhone's CPU, which comes out to about 70 million clock cycles. Performance studies of AES on a Cortex-A8 show about 25 cycles per byte for encryption plus 236 cycles for the key schedule. The key schedule setup only has to be done once so if the key is 32 bytes then we have 800 cycles per iteration, or about 87,500 iterations.

It's hard to give exact performance numbers for AES bruteforcing on an FPGA without building a cracker, but if pipelined to one guess per clock cycle at 400 MHz (reasonable for a modern 28nm FPGA) an attacker could easily get around 4500 guesses per second per hash pipeline. Assuming at least two pipelines per FPGA, the proposed FPGA cluster would give 22.5 million guesses per second - sufficient to break a 6-character case-sensitive alphanumeric password in around half an hour. If we limit ourselves to lowercase letters and numbers only, it would only take 45 seconds instead of the five and a half years Apple claims bruteforcing on the phone would take. Even 8-character alphanumeric case-sensitive passwords could be within reach (about eight weeks on average, or faster if the password contains predictable patterns like dictionary words).

by Andrew Zonenberg (noreply@blogger.com) at January 16, 2015 09:31 PM

Hello 2015 - New job, new projects, and more!

A few months ago, I wrote about some of my pending projects. Several of them are actively running, some are done, and a few new ones cropped up :) I'll be making a bunch of short posts in the next day or so on some of them.

It's been a busy fall so I haven't had time to post anything lately. I'm working hard on my thesis and plan to defend this spring. It's 84 pages and counting...

After I graduate I'll be packing up my lab and moving from Troy, NY to somewhere near Seattle. I'll be working as a senior security consultant in the hardware lab at IOActive, doing board, firmware, and silicon level reversing and security auditing, as well as original research... so you can expect some posts by me on their lab blog in the coming months. My personal lab will likely have a bit of downtime due to the move, although I'd like to get back up and running by the end of the summer at the latest.

I've also submitted a talk based on my CPLD reverse engineering work to REcon. I hinted earlier about the project but there's a lot more to it which hasn't been released publicly... details to come if the talk is accepted ;)

by Andrew Zonenberg (noreply@blogger.com) at January 16, 2015 09:31 PM

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 January 16, 2015 09:30 PM

New microscope bench

For a long time, my microscopes have lived on a folding plastic table in the corner of my lab. It was wobbling and causing blurry images, but I never got a chance to do something about it... until now.

It's been replaced it with a custom-built wooden workbench. I made it big and heavy on purpose to reduce vibrations: The tabletop is 3/4" flooring-grade plywood and the legs are 4x4" posts resting on top of rubber pads. (I actually made two of them, because one of my roommates liked the design and wanted one for himself. )

I don't have any photos of the early build process but here's one of the tabletop and legs before the shelving was installed. It was annoying having to stain and assemble it in the middle of my living room... I can't wait to have a garage or basement to work in!

EDIT: A friend who helped me with the build just sent me this one.
Test-fitting some of the lumber
New workbench, partially assembled
After installing shelves
In its final resting place

The stain turned out a little darker than I anticipated but it actually matched the paneling in my apartment surprisingly well so no complaints there. The 16 square feet of shelf space let me tidy up the lab and remove a lot of miscellaneous junk that had been sitting around with nowhere to go.

With equipment installed
It was a lot of fun to make - I had almost forgotten how much I enjoyed woodworking. Maybe my next piece of furniture will be something more pretty and less utilitarian in nature? (Making it out of hardwood instead of construction lumber, and having better tools, would help too...)

by Andrew Zonenberg (noreply@blogger.com) at January 16, 2015 09:25 PM

FPGA cluster updates


Although the "raised floor" design for my FPGA cluster looked cool, it really didn't scale. My entire desk was full, there was very limited room for new hardware, and the boards kept getting dusty. To make matters worse, long wires were needed to connect everything and it was difficult to manage them all.

Original FPGA cluster

I ended up moving forward with the plan I came up with a few months ago and my FPGA cluster is now living on the 19" rack in my living room.

The first step was to laser-cut acrylic frames for each board (or several boards, if they were small enough) that would slide into the card guides.

In the photo below you can see nodes lx9mini0 and lx9mini2 (lx9mini1 was being used for something else at the time so I put it on another card later on) on a clear 1/16" acrylic sheet cut to standard Eurocard dimensions. The clear faceplate was later replaced with an opaque black one because I think it looks better that way.

Spartan-6 FPGA boards on a 3U blade card

My existing USB hubs weren't well suited to the rackmount form factor so I built a new one. This is a ten-port USB 2.0 hub with two front-panel ports (for keyboard and mouse) and eight back-side ports for internal connections. It consists of three 4-port Cypress hub chips in a tree, plus the associated PMICs. For extra fun I threw on an XC2C128 CPLD with a SPI headers so that I could potentially toggle power to individual ports remotely over SPI, but as of now this functionality isn't being used.

As with my previous hub designs all ports are overcurrent protected. I also added external ESD clamp diodes (RCLAMP0514M) to each data line after an killing a previous hub by zapping it while plugging my phone in to charge.

The port indicator LEDs are off in the idle state, green when a device has enumerated successfully, blinking green when a device is detected but fails to enumerate, and red for an overcurrent fault.

3U x 4HP USB hub blade


I went with my original plan of racking the Atlys boards in one of my empty 1U cases and the AC701 in another. The boards are screwed into standoffs which are attached to the case by cyanoacrylate adhesive.

Nodes atlys0 and atlys1 being installed in a 1U server case. JTAG and Ethernet cables are not yet installed.

I then installed my PDU board, the BeagleBone Black, the USB hub, and all of the smaller FPGA boards I was using for my research in the rack. Since I was moving the second 24-port switch from my desk to the rack I hooked the two together with a short run of multimode fiber. Fiber was overkill for the application but I had SFP ports sitting around unused and I was running out of copper interfaces...

The standard I've decided on for all new designs in the near future is as follows:
  • Boards are to be 100mm tall (3U Eurocard height)
  • Component keepouts along the top and bottom edges as specified by the Eurocard standard for card guides
  • Faceplate mounting holes on the front panel as specified by the Eurocard standard
  • 5V DC center-high power via standard 5.5mm barrel jack on the back edge
  • Network jacks and indicator LEDs on the front edge
  • JTAG, USB, and other I/O on the back edge

My current rack
The current FPGA cluster
Back side of the FPGA cluster midway through rack install. The USB cable coming out the bottom was temporary for testing until I could find a right-angle one.
All of the cards have nice shiny black faceplates except my 4-port switch prototype from a few years ago - the laser cutter on campus was unavailable the day I wanted to get the faceplate made and I never got around to doing it.

I still have quite a bit more gear to rack - several Spartan-6 boards I'm not actively using in my research, a Raspberry Pi, a Parallella, and a large number of PIC MCU development boards of various types. This will fill the current card rack and then some, so I left 3U of empty space below this one for expansion. The Parallella runs hot so I ordered a 1U fan tray which will be installed later today.

The 1U blank above the card rack is there for airflow reasons (the fan will blow upwards and exhaust air needs some space to blow out) but I can still fit stuff that doesn't block airflow. Early next week I'll be replacing it with a 16-port LC-LC patch panel so that I can terminate fiber runs to various devices on the rack (such as the AC701 board, which currently has a 2m run of multimode going around the side of the rack because there's no good way to get fiber from back to front).

by Andrew Zonenberg (noreply@blogger.com) at January 16, 2015 09:25 PM

GERALD microscope control system

While my optical microscopes are capable of sufficient resolution for imaging larger-process ICs, taking massive die images (this one, for a comparatively small 3.2mm^2 die, is about 0.6 gigapixels) has been beyond my capability because I have better things to do with my time than sit in the lab for a week turning the stage knob a little, clicking a button to take a picture, turning the knob a little...

John has a computer-controlled microscope that he uses for large imaging jobs and it seemed like it'd be a good idea to make one of my own. The first step was to write some control software. John's user interface is very much a "programmer's GUI" and I figured something with a bit more eye candy wouldn't be too hard to do.

The result was a system called GERALD. (I couldn't think of a name for it, asked my girlfriend for suggestions, and this was the first she came up with...)

The prototype is using my old AmScope microscope because I didn't want to take my main Olympus out of service for an extended period of time during development. Yes, I'm aware that the "support" structure under the stage isn't very rigid... this is a software development testbed and I won't be using this microscope in the final deployment so there's no sense wasting time machining nice aluminum brackets. I just have to be careful not to move around too much when using it ;)

Prototype GERALD system on my desk. The breadboarded MCU is generating step/direction pulses from USB-serial commands and sending them to the stepper controller under the textbook.

The camera in use is an AmScope MD1900. It uses a proprietary USB protocol and only has Windows driver support, and I try to run a 100% Linux shop. This was a problem... In keeping with John's unofficial motto "Open source by any means necessary", I corrected the problem ;)

A bit of Wireshark and libusb coding later, I had a basic working driver. The protocol is closely related (but not identical) to the MU800 that John reversed a few months ago, which helped me get my feet in the door. There's a bit of trivial obfuscation (XORing control transactions with 0x55aa or 0x5aa5) which I fail to understand... The average user isn't going to notice anything, and anyone with the skills to reverse engineer USB transactions or a kernel driver will see right through it, so why bother?

I plan to try making a kernel V4L2 driver in the future but for now it works so it's not a huge priority.


The current GERALD system is very much a WIP, most basic features are there but automated image capture and some other things aren't implemented yet.

GERALD UI overview
The basic UI layout is modeled in large part on the FEI Versa FIB's control system, which is currently my favorite control system for either optical or electron microscopes.

The upper left panel is an overview of the current camera feed, scaled down to fit. The upper right view, meanwhile, shows the center of the feed at native (1:1 pixel) resolution. Both views have a footer that includes a scale bar, date/time, the objective in use, and magnification. (The magnification is the actual value based on calibration of the camera and my 24" 1080p display.)

The lower right view is a webcam pointed at the sample stage. I haven't had the time to make a bracket to hold it in the right spot so it's just sitting on my desk for now. This is the equivalent of a SEM chamber cam and I hope to eventually use it to avoid crashing the sample into the objective in full-remote-control operation.

The lower left view is a navigation display showing the current sample. Unlike the Versa's nav-cam (a single static image taken of the stage when the sample is loaded) my navigation view is a composite of actual microscope images. Every time a new video frame comes in when the stage isn't moving (to avoid motion blur) it is plotted in the navigation view at the current physical position of the stage.

As of now the navigation view is non-interactive; all it does is show the current field of view on the sample. My plan is to support clicking to move the stage to a specific point, as well as drawing to define a rectangular area for step-and-repeat imaging.

In typical use I envision the user moving to the upper left and bottom right corner of the sample manually with the joystick, then selecting an objective and drawing a box around the sample to initiate a high-resolution imaging run.

In order for all of this to work properly, the system must be calibrated. The first step is to calibrate the camera so that it knows how large each pixel is. I've done this manually in the past by taking pictures of a calibration slide and counting pixels, but it's high time I automated the process.

GERALD pixel size calibration
The algorithm is quite simple and is designed to work with the pattern on my calibration slide (10um pitch short lines and 50um pitch long lines) only. As of now the are limited sanity checks so if there's no calibration slide in view the results can be somewhat strange :)
  • Convert the image to grayscale using NTSC color weights
  • Compute a gray-level histogram
  • Median-filter the histogram to smooth out spikes and find peaks
  • The distribution should be approximately bimodal (white lines on dark background). Take the mean of the peaks and threshold the image to binary.
  • Do a median filter on the binary image to smooth out noise
  • Scan across the image horizontally, one scan line at a time. Note the start and end locations of each white area. If the width is too small (less than two pixels) or too large (more than 10% of the screen) discard it. Otherwise save the width and centroid as a slice down a potential line.
  • For each slice, check if the next row down has a line slice within a couple of pixels. If so, add it to the growing polyline and remove it from the list of candidates.
  • Fit a line segment to the points in each polyline using least-squares, set its width to the mean of all slices used
  • Extend each line segment until it hits the edge of the image. If the projected line gets within a very short distance of BOTH endpoints of a second segment, the two are collinear so merge them. (This will smooth out gaps in the detected lines from dust specks etc.) The resulting lines are plotted in green in the calibration view.
  • Project the lines onto the X axis and sort them from left to right.
  • For each line from left to right, measure the perpendicular distance to the next one over (displayed in red in the calibration view).
  • Compute the median of these line lengths. This is considered to be the pitch of the lines, in pixels.
  • Find the median width of the lines.
  • If the pitch is less than three times the line width, we're looking at fine-pitch lines (10 μm pitch). Otherwise the fine pitch lines were too small to resolve and we're looking at coarse pitch (50 μm).
  • Compute the physical size of one camera pixel from the known physical pitch and pixel pitch.
Now that that the camera has been calibrated, we know how big a camera pixel is - but we don't have the scaling and rotation factors needed to transform between camera and stage coordinates. This is the second half of the calibration.

Rather than trying to compute a full transformation matrix, the current code simply represents a motor step for each motor as a 2-vector describing the distance (in nanometers, referenced to the camera axes) the stage moves during one motor step. We can then easily compute the distance moved by any number of motor steps as a linear combination of these two 2-vectors.

This algorithm is built on top of the same CV code used for the camera calibration.
  • Find the rightmost line on the calibration slide.
  • Locate the midpoint of it. (This is marked with a blue dot in the debug overlay.)
  • Check if this keypoint is in the left 1/4 of the camera's FOV.
  • If not, move left 50 steps, take a picture, and repeat until it is.
  • Record the position of the keypoint.
  • Move right, 50 steps at a time, until the keypoint is in the right 1/4 of the FOV.
  • Record the 2D distance the keypoint moved and divide by the number of steps taken to get the X axis step vector.
  • Repeat for the Y axis, except using 1/3 as the threshold instead of 2/3 since the Y axis FOV is smaller than X.

The system isn't quite finished but it's coming along nicely. Hopefully I'll have time in the next couple of months to finish the software, make a PCB for the control circuit, and machine brackets to hold all of the parts onto my Olympus scope.

by Andrew Zonenberg (noreply@blogger.com) at January 16, 2015 09:25 PM

January 13, 2015

Video Circuits

Video Glitch Device

Here is a device I built for a fellow artist, there are a few shots of its slowly disrupting a shot of a grid to give you an idea off the effects it can produce.






by Chris (noreply@blogger.com) at January 13, 2015 02:56 PM

Lorene Lavora

Some early computer art stills from 1983 by Lorene Lavora



by Chris (noreply@blogger.com) at January 13, 2015 02:44 PM

January 09, 2015

Richard Hughes, ColorHug

Finding hidden applications with GNOME Software

When you do a search in GNOME Software it returns any result of any application with AppStream metadata and with a package name it can resolve in any remote repository. This works really well for software you’re installing from the main distribution repos, but less well for some other common cases.

Lets say I want to install Google Chrome so that my 2 year old daughter can ring me on hangouts, and tell me that dinner is ready. Lets search for Chrome on my Fedora Rawhide system.

Screenshot from 2015-01-09 16:37:45

Whoa! Wait, how did you do that? First, this exists in /etc/yum.repos.d/google-chrome.repo — the important line being enabled_metadata=1. This means “download just the metadata even when enabled=0” and means we can get information about what packages are available in repos we are not enabling by default for legal or policy reasons.

[google-chrome]
name=google-chrome
baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64
enabled=0
gpgcheck=1
repo_gpgcheck=1
enabled_metadata=1
gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub

We’ve also got a little XML document with the AppStream metadata (just the long description and keywords) called /usr/share/app-info/xmls/google-chrome.xml which could be included in the usual vendor-supplied fedora-22.xml if that’s what we want to do.

Screenshot from 2015-01-09 16:40:09

The other awesome feature this unlocks is when we have addon repos that are not enabled by default. For instance, my utopia repo full of super new free software applications could be included in Fedora, and if the user types in the search word we ask if the repo should be enabled. This would solve a lot of use cases if we could ship .repo files for a few popular COPRs of stuff we don’t (yet) ship in Fedora, but are otherwise free and open source software.

Screenshot from 2015-01-09 16:51:00

All the components to do this are upstream in Fedora 22 (you need a new librepo, libhif, PackageKit, libappstream-glib and gnome-software, phew!) although I’m sure we’ll be tweaking the UI and UX before Fedora 22 is released. Comments welcome.

 

by hughsie at January 09, 2015 08:01 PM

Uwe Hermann

My GPG key transition to a 4096-bit key

This is long overdue, so here goes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1,SHA512

I'm transitioning my GPG key from an old 1024D key to a new 4096R key.

The old key will continue to be valid for some time, but I prefer
all new correspondance to be encrypted to the new key, and will be making
all signatures going forward with the new key.

This transition document is signed with both keys to validate the transition.

If you have signed my old key, I would appreciate signatures on my new
key as well, provided that your signing policy permits that without
re-authenticating me.

Old key:

pub   1024D/0x5DD5685778D621B4 2000-03-07
      Key fingerprint = 0F3C 34D1 E4A3 8FC6 435C  01BA 5DD5 6857 78D6 21B4

New key:

pub   4096R/0x1D661A372FED8F94 2013-12-30
      Key fingerprint = 9A17 578F 8646 055C E19D  E309 1D66 1A37 2FED 8F94

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlSwEaIACgkQXdVoV3jWIbQW5QCgoFHVU/D4fKSbvmGv3nNy3MAW
S2UAn075ztmxQ8Y9/22crbUug1sEjfh5iQIcBAEBCgAGBQJUsBGiAAoJEB1mGjcv
7Y+U9PgP/29jPvrNcdWsLI8YK9U6+JzS+TMXNyfp6CQXc8O/+zJwqvvxNpqY3rLM
5otRLIEJ2EVdiF8sCWTDGusS9NkMePzumR0AFAR0iltIkekO5O0HbHhK0sXJQv0s
EipDpFRO9k4/CBpJEy6Pkkxwd3ndtmwrL1/oKeVmM4E62PJd9ofMpQb/gMUsrA8u
F8xoOXY8Os82Rrd759PypSxNecjd6SYaVJTHgFbZ0QIMJkdKaufifzARdw+v5jwg
8Q11BhpYxvUSugZgiciKA6RjRK5bfRnT8VQPFd0zneilsIW13zz/jub9df/vtM5L
vY/6jHvXczYXSG8EGpHJQCD3KtQJPWZ0Nz9rAm4emEPmR2qav6KGARatYAm0RBqZ
Y81YUEuiWzGli6DH1m9SQe8bqM/J94vQAAX9VqUn2gz0Z0Ey25kVQE7NOGsbbGVS
vD/E74FSk1At9/RGpstrfEjsDKPRman2xk/oZe+08sRB22CJl40N4tZV9AkCJNom
HHGZKp+VEKaCEiLUIRjKTHt2HTThg39zmxl+OnoTSFYvloxrDJyi9SxZgCAmBhbD
7kLkaSDmdUj6CmoilGU+gd2zmQl2D+RHinYZBxOUf1vi1MDLWNcLIMgrz4mRXgzE
YKkG0newf9UbyJw42sXe2ukNQBIqBcL/DmAhG7V+r0RD7MQnMEYy
=09bN
-----END PGP SIGNATURE-----

The new key is available from keyservers, e.g. pgp.mit.edu or others.

In other news: Yes, I've not been blogging much recently, will try to do updates more often. In the mean time, you can also refer to my Twitter account for random stuff or the new sigrok Twitter account for sigrok-related posts.

by Uwe Hermann at January 09, 2015 04:47 PM

Richard Hughes, ColorHug

GNOME MultiWriter 3.15.2

I’ve just released GNOME MultiWriter 3.15.2, which is the first release that makes it pretty much feature complete for me.

Reads and writes are now spread over root hubs to increase throughput. If you’ve got a hub with more than 7 ports and the port numbers don’t match the decals on the device please contact me for more instructions.

In this release I’ve also added the ability to completely wipe a drive (write the image, then NULs to pad it out to the size of the media) and made that and the verification step optional. We also now show a warning dialog to the user the very first time the application is used, and some global progress in the title bar so you can see the total read and write throughput of the application.

With this release I’ve now moved the source to git.gnome.org and will do future releases to ftp.gnome.org like all the other GNOME modules. If you see something obviously broken and you have GNOME commit access, please just jump in and fix it. The translators have done a wonderful job using transifex, but now I’m leaving the just-as-awesome GNOME translator teams handle localisation.

If you’ve got a few minutes, and want to try it out, you can clone the git repo or install a package for Fedora.

Richard

by hughsie at January 09, 2015 01:03 PM

January 08, 2015

ZeptoBARS

Noname MMBT3904 - npn BJT transistor : weekend die-shot

On the first glance it looks very similar to NXP PMST3904, but topology is clearly redrawn. Notice sketchy borders of metalization - apparently they were using lift-off process for metalization instead of plasma etching. But for discrete transistors this might still be acceptable for good yield.

Die size 290x291 µm, which is slightly larger than NXP's one.


January 08, 2015 03:12 PM

Video Circuits

Denise Gallant, Satellite 1986

"Inspired by the book "Voyage to Acturus", Satellite was released in 1986. This 34 minute video was produced by Denise Gallant with a grant from the American Film Institute and National Endowment For The Arts."

by Chris (noreply@blogger.com) at January 08, 2015 05:09 AM

January 05, 2015

Richard Hughes, ColorHug

GNOME MultiWriter and Large Hubs

Today I released the first version of GNOME MultiWriter, and built it for Rawhide and F21. It’s good enough for a first release, although there are still a few things left to do. The most important now is probably the self-profiling mode so that we know the best number of parallel threads to use for the read and the write. I want this to Just Work without any user interaction, but I’ll have to wait for my shipment of USB drives to arrive before I can add that functionality.

Also important to the UX is how we display failed devices. Most new USB devices accept the ISO image without a fuss, but the odd device will disconnect before completion or throw a write error. In this case it’s important to know which device is the one that belongs in the rubbish bin. This is harder than you think, as the electrical port number is not always what matches the decal on the plastic box.

For my test system I purchased a 10-port USB hub. I was interested to know how the vendor implemented this, as I don’t know of a SOIC chip that can drive more than 7 ports. It turns out, my 10-port hub is actually a 4-port hub, with a 7-port hub attached to the last port of the first hub. The second hub was also wired 1,2,3,4,7,6,5 rather than 1,2,3,4,5,6,7. This could cause my dad some issues when we tell him that device #5 needs removing.

I’ve merged some code into GNOME MultiWriter to work around this, but if you’ve got a hub with >7 ports I’d be interested to know if this works for you, or if we need to add some more VID/PID matches. If you do try this out you need libgusb from git master today. Helpfully gnome-multi-writer outputs quirk info to the command line if you use --verbose, so that makes debugging this stuff easier.

by hughsie at January 05, 2015 10:48 PM

January 02, 2015

Richard Hughes, ColorHug

Introducing GNOME MultiWriter

I spent last night writing a GNOME application to duplicate a ton of USB devices. I looked at mdcp, Clonezilla and also just writing something loopy in bash, but I need something simple my dad could use for a couple of hours a week without help.

It’s going to be super useful for me when I start sending our LiveUSB disks in the ColorHug box (rather than LiveCDs) and possibly useful to other people just wanting to copy a USB drive for QA testing on a small group of people, a XFCE live CD of Fedora rawhide for a code sprint, and that kind of thing.

GNOME MultiWriter allows you to write and verify an ISO file to up to 20 USB devices at once.

Screenshot from 2015-01-02 16:24:35

Bugs (and especially pull requests) accepted on GitHub; if there’s sufficient interest I’ll move the project to git.gnome.org after a few releases.

by hughsie at January 02, 2015 04:45 PM

Dan Reetz

Struggling to pay rent. GoPro to the rescue.

Like any reasonable person, my landlord wants a check shoved under an unmarked door in the basement. Problem is, at night an on the weekends, the door leading to the basement is locked. I am so motivated to pay my landlord that I jammed a credit card into the door to try to open it. Anyone who has tried this “trick” knows that 9 times out of 10 you just break off the damned card and the door remains locked.

As it turns out, Dana was just sponsored by GoPro, so I have around 7 metric shit-tons of GoPro garbage in my workshop. The lexan-like material that they use in their packaging felt flexible enough to be a good shim.

2015-01-01 17.19.47

Dimensions unimportant. Big enough so you can grab on with two hands.
2015-01-01 17.08.42

2015-01-01 17.04.45

Start high above the latch and work down. Use force.
2015-01-01 17.05.16

Yep.
2015-01-01 17.05.29

by danreetz at January 02, 2015 01:33 AM

December 28, 2014

Bunnie Studios

From Gongkai to Open Source

About a year and a half ago, I wrote about a $12 “Gongkai” cell phone (pictured above) that I stumbled across in the markets of Shenzhen, China. My most striking impression was that Chinese entrepreneurs had relatively unfettered access to cutting-edge technology, enabling start-ups to innovate while bootstrapping. Meanwhile, Western entrepreneurs often find themselves trapped in a spiderweb of IP frameworks, spending more money on lawyers than on tooling. Further investigation taught me that the Chinese have a parallel system of traditions and ethics around sharing IP, which lead me to coin the term “gongkai”. This is deliberately not the Chinese word for “Open Source”, because that word (kaiyuan) refers to openness in a Western-style IP framework, which this not. Gongkai is more a reference to the fact that copyrighted documents, sometimes labeled “confidential” and “proprietary”, are made known to the public and shared overtly, but not necessarily according to the letter of the law. However, this copying isn’t a one-way flow of value, as it would be in the case of copied movies or music. Rather, these documents are the knowledge base needed to build a phone using the copyright owner’s chips, and as such, this sharing of documents helps to promote the sales of their chips. There is ultimately, if you will, a quid-pro-quo between the copyright holders and the copiers.

This fuzzy, gray relationship between companies and entrepreneurs is just one manifestation of a much broader cultural gap between the East and the West. The West has a “broadcast” view of IP and ownership: good ideas and innovation are credited to a clearly specified set of authors or inventors, and society pays them a royalty for their initiative and good works. China has a “network” view of IP and ownership: the far-sight necessary to create good ideas and innovations is attained by standing on the shoulders of others, and as such there is a network of people who trade these ideas as favors among each other. In a system with such a loose attitude toward IP, sharing with the network is necessary as tomorrow it could be your friend standing on your shoulders, and you’ll be looking to them for favors. This is unlike the West, where rule of law enables IP to be amassed over a long period of time, creating impenetrable monopoly positions. It’s good for the guys on top, but tough for the upstarts.

This brings us to the situation we have today: Apple and Google are building amazing phones of outstanding quality, and start-ups can only hope to build an appcessory for their ecosystem. I’ve reviewed business plans of over a hundred hardware startups by now, and most of them are using overpriced chipsets built using antiquated process technologies as their foundation. I’m no exception to this rule – we use the Freescale i.MX6 for Novena, which is neither the cheapest nor the fastest chip on the market, but it is the one chip where anyone can freely download almost complete documentation and anyone can buy it on Digikey. This parallel constraint of scarce documentation and scarce supply for cutting edge technology forces Western hardware entrepreneurs to look primarily at Arduino, Beaglebone and Raspberry Pi as starting points for their good ideas.


Above: Every object pictured is a phone. Inset: detail of the “Skeleton” novelty phone. Image credits: Halfdan, Rachel Kalmar

Chinese entrepreneurs, on the other hand, churn out new phones at an almost alarming pace. Phone models change on a seasonal basis. Entrepreneurs experiment all the time, integrating whacky features into phones, such as cigarette lighters, extra-large battery packs (that can be used to charge another phone), huge buttons (for the visually impaired), reduced buttons (to give to children as emergency-call phones), watch form factors, and so forth. This is enabled because very small teams of engineers can obtain complete design packages for working phones – case, board, and firmware – allowing them to fork the design and focus only on the pieces they really care about.

As a hardware engineer, I want that. I want to be able to fork existing cell phone designs. I want to be able to use a 364 MHz 32-bit microcontroller with megabytes of integrated RAM and dozens of peripherals costing $3 in single quantities, instead of a 16 MHz 8-bit microcontroller with a few kilobytes of RAM and a smattering of peripherals costing $6 in single quantities. Unfortunately, queries into getting a Western-licensed EDK for the chips used in the Chinese phones were met with a cold shoulder – our volumes are too small, or we have to enter minimum purchase agreements backed by hundreds of thousands of dollars in a cash deposit; and even then, these EDKs don’t include all the reference material the Chinese get to play with. The datasheets are incomplete and as a result you’re forced to use their proprietary OS ports. It feels like a case of the nice guys finishing last. Can we find a way to still get ahead, yet still play nice?

We did some research into the legal frameworks and challenges around absorbing Gongkai IP into the Western ecosystem, and we believe we’ve found a path to repatriate some of the IP from Gongkai into proper Open Source. However, I must interject with a standard disclaimer: we’re not lawyers, so we’ll tell you our beliefs but don’t construe them as legal advice. Our intention is to exercise our right to reverse engineer in a careful, educated fashion to increase the likelihood that, if push comes to shove, the courts will agree with our actions. However, we also feel that shying away from reverse engineering simply because it’s controversial is a slippery slope: you must exercise your rights to have them. If women didn’t vote and black people sat in the back of the bus because they were afraid of controversy, the US would still be segregated and without universal suffrage.

Sometimes, you just have to stand up and assert your rights.

There are two broad categories of issues we have to deal with, patents and copyrights. For patents, the issues are complex, yet it seems the most practical approach is to essentially punt on the issue. This is what the majority of the open source community does, and in fact many corporations have similar policies at the engineering level. Nobody, as far as we know, checks their Linux commits for patent infringement before upstreaming them. Why? Among other reasons, it takes a huge amount of resources to determine which patents apply, and if one could be infringing; and even after expending those resources, one cannot be 100% sure. Furthermore, if one becomes very familiar with the body of patents, it amplifies the possibility that an infringement, should it be found, is willful and thus triple damages. Finally, it’s not even clear where the liability lies, particularly in an open source context. Thus, we do our best not to infringe, but cannot be 100% sure that no one will allege infringement. However, we do apply a license to our work which has a “poison pill” clause for patent holders that do attempt to litigate.

For copyrights, the issue is also extremely complex. The EFF’s Coders’ Rights Project has a Reverse Engineering FAQ that’s a good read if you really want to dig into the issues. The tl;dr is that courts have found that reverse engineering to understand the ideas embedded in code and to achieve interoperability is fair use. As a result, we have the right to study the Gongkai-style IP, understand it, and produce a new work to which we can apply a Western-style Open IP license. Also, none of the files or binaries were encrypted or had access controlled by any technological measure – no circumvention, no DMCA problem.

Furthermore, all the files were obtained from searches linking to public servers – so no CFAA problem, and none of the devices we used in the work came with shrink-wraps, click-throughs, or other end-user license agreements, terms of use, or other agreements that could waive our rights.

Thus empowered by our fair use rights, we decided to embark on a journey to reverse engineer the Mediatek MT6260. It’s a 364 MHz, ARM7EJ-S, backed by 8MiB of RAM and dozens of peripherals, from the routine I2C, SPI, PWM and UART to tantalizing extras like an LCD + touchscreen controller, audio codec with speaker amplifier, battery charger, USB, Bluetooth, and of course, GSM. The gray market prices it around $3/unit in single quantities. You do have to read or speak Chinese to get it, and supply has been a bit spotty lately due to high Q4 demand, but we’re hoping the market will open up a bit as things slow down for Chinese New Year.

For a chip of such complexity, we don’t expect our two-man team to be able to unravel its entirety working on it as a part-time hobby project over the period of a year. Rather, we’d be happy if we got enough functionality so that the next time we reach for an ATMega or STM32, we’d also seriously consider the MT6260 as an alternative. Thus, we set out as our goal to port NuttX, a BSD-licensed RTOS, to the chip, and to create a solid framework for incrementally porting drivers for the various peripherals into NuttX. Accompanying this code base would be original hardware schematics, libraries and board layouts that are licensed using CC BY-SA-3.0 plus an Apache 2.0 rider for patent issues.

And thus, the Fernvale project was born.

Fernvale Hardware

Compared to the firmware, the hardware reverse engineering task was fairly straightforward. The documents we could scavenge gave us a notion of the ball-out for the chip, and the naming scheme for the pins was sufficiently descriptive that I could apply common sense and experience to guess the correct method for connecting the chip. For areas that were ambiguous, we had some stripped down phones I could buzz out with a multimeter or stare at under a microscope to determine connectivity; and in the worst case I could also probe a live phone with an oscilloscope just to make sure my understanding was correct.

The more difficult question was how to architect the hardware. We weren’t gunning to build a phone – rather, we wanted to build something a bit closer to the Spark Core, a generic SoM that can be used in various IoT-type applications. In fact, our original renderings and pin-outs were designed to be compatible with the Spark ecosystem of hardware extensions, until we realized there were just too many interesting peripherals in the MT6260 to fit into such a small footprint.


Above: early sketches of the Fernvale hardware

We settled eventually upon a single-sided core PCB that we call the “Fernvale Frond” which embeds the microUSB, microSD, battery, camera, speaker, and Bluetooth functionality (as well as the obligatory buttons and LED). It’s slim, at 3.5mm thick, and at 57x35mm it’s also on the small side. We included holes to mount a partial set of pin headers, spaced to be compatible with an Arduino, although it can only be plugged into 3.3V-compatible Arduino devices.


Above: actual implementation of Fernvale, pictured with Arduino for size reference

The remaining peripherals are broken out to a pair of connectors. One connector is dedicated to GSM-related signals; the other to UI-related peripherals. Splitting GSM into a module with many choices for the RF front end is important, because it makes GSM a bona-fide user-installed feature, thus pushing the regulatory and emissions issue down to the user level. Also, splitting the UI-related features out to another board costs down the core module, so it can fit into numerous scenarios without locking users into a particular LCD or button arrangement.


Above: Fernvale system diagram, showing the features of each of the three boards


Fernvale Frond mainboard


Fernvale blade UI breakout


Fernvale spore AFE dev board

All the hardware source documents can be downloaded from our wiki.

As an interesting side-note, I had some X-rays taken of the MT6260. We did this to help us identify fake components, just in case we encountered units being sold as empty epoxy blocks, or as remarked versions of other chips (the MT6260 has variants, such as the -DA and the -A, the difference being how much on-chip FLASH is included).


X-ray of the MT6260 chip. A sharp eye can pick out the outline of multiple ICs among the wirebonds. Image credit: Nadya Peek

To our surprise, this $3 chip didn’t contain a single IC, but rather, it’s a set of at least 4 chips, possibly 5, integrated into a single multi-chip module (MCM) containing hundreds of wire bonds. I remember back when the Pentium Pro’s dual-die package came out. That sparked arguments over yielded costs of MCMs versus using a single bigger die; generally, multi-chip modules were considered exotic and expensive. I also remember at the time, Krste Asanović, then a professor at the MIT AI Lab now at Berkeley, told me that the future wouldn’t be system on a chip, but rather “system mostly on a chip”. The root of his claim is that the economics of adding in mask layers to merge DRAM, FLASH, Analog, RF, and Digital into a single process wasn’t favorable, and instead it would be cheaper and easier to bond multiple die together into a single package. It’s a race between the yield and cost impact (both per-unit and NRE) of adding more process steps in the semiconductor fab, vs. the yield impact (and relative reworkability and lower NRE cost) of assembling modules. Single-chip SoCs was the zeitgeist at the time (and still kind of is), so it’s interesting to see a significant datapoint validating Krste’s insight.

Reversing the Boot Structure

The amount of documentation made available to Shanzhai engineers in China seems to be just enough to enable them to assemble a phone and customize its UI, but not enough to do a full OS port. You eventually come to recognize that all the phones based on a particular chipset have the same backdoor codes, and often times the UI is inconsistent with the implemented hardware. For example, the $12 phone mentioned at the top of the post will prompt you to plug headphones into the headphone jack for the FM radio to work, yet there is no headphone jack provided in the hardware. In order to make Fernvale accessible to engineers in the West, we had to reconstruct everything from scratch, from the toolchain, to the firmware flashing tool, to the OS, to the applications. Given that all the Chinese phone implementations simply rely upon Mediatek’s proprietary toolchain, we had to do some reverse engineering work to figure out the boot process and firmware upload protocol.

My first step is always to dump the ROM, if possible. We found exactly one phone model which featured an external ROM that we could desolder (it uses the -D ROMless variant of the chip), and we read its contents using a conventional ROM reader. The good news is that we saw very little ciphertext in the ROM; the bad news is there’s a lot of compressed data. Below is a page from our notes after doing a static analysis on the ROM image.

0x0000_0000		media signature “SF_BOOT”
0x0000_0200		bootloader signature “BRLYT”, “BBBB”
0x0000_0800		sector header 1 (“MMM.8”)
0x0000_09BC		reset vector table
0x0000_0A10		start of ARM32 instructions – stage 1 bootloader?
0x0000_3400		sector header 2 (“MMM.8”) – stage 2 bootloader?
0x0000_A518		thunk table of some type
0x0000_B704		end of code (padding until next sector)
0x0001_0000		sector header 3( “MMM.8”) – kernel?
0x0001_0368		jump table + runtime setup (stack, etc.)
0x0001_0828		ARM thumb code start – possibly also baseband code
0x0007_2F04		code end
0x0007_2F05 – 0x0009_F0005	padding “DFFF”
0x0009_F006		code section begin “Accelerated Technology / ATI / Nucleus PLUS”
0x000A_2C1A		code section end; pad with zeros
0x000A_328C		region of compressed/unknown data begin
0x007E_E200		modified FAT partition #1
0x007E_F400		modified FAT partition #2

One concern about reverse engineering SoCs is that they have an internal boot ROM that is always run before code is loaded from an external device. This internal ROM can also have signature and security checks that prevent tampering with the external code, and so to determine the effort level required we wanted to quickly figure out how much code was running inside the CPU before jumping to external boot code. This task was made super-quick, done in a couple hours, using a Tek MDO4104B-6. It has the uncanny ability to take deep, high-resolution analog traces and do post-capture analysis as digital data. For example, we could simply probe around while cycling power until we saw something that looked like RS-232, and then run a post-capture analysis to extract any ASCII text that could be coded in the analog traces. Likewise, we could capture SPI traces and the oscilloscope could extract ROM access patterns through a similar method. By looking at the timing of text emissions versus SPI ROM address patterns, we were able to quickly determine that if the internal boot ROM did any verification, it was minimal and nothing approaching the computational complexity of RSA.


Above: Screenshot from the Tek MDO4104B-6, showing the analog trace in yellow, and the ASCII data extracted in cyan. The top quarter shows a zoomed-out view of the entire capture; one can clearly see how SPI ROM accesses in gray are punctuated with console output in cyan.

From here, we needed to speed up our measure-modify-test loop; desoldering the ROM, sticking it in a burner, and resoldering it onto the board was going to get old really fast. Given that we had previously implemented a NAND FLASH ROMulator on Novena, it made sense to re-use that code base and implement a SPI ROMulator. We hacked up a GPBB board and its corresponding FPGA code, and implemented the ability to swap between the original boot SPI ROM and a dual-ported 64kiB emulator region that is also memory-mapped into the Novena Linux host’s address space.


Block diagram of the SPI ROMulator FPGA


There’s a phone in my Novena! What’s that doing there?

A combination of these tools – the address stream determined by the Tek oscilloscope, rapid ROM patching by the ROMulator, and static code analysis using IDA (we found a SHA-1 implementation) – enabled us to determine that the initial bootloader, which we refer to as the 1bl, was hash-checked using a SHA-1 appendix.

Building a Beachhead

The next step was to create a small interactive shell which we could use as a beachhead for running experiments on the target hardware. Xobs created a compact REPL environment called Fernly which supports commands like peeking and poking to memory, and dumping CPU registers.

Because we designed the ROMulator to make the emulated ROM appear as a 64k memory-mapped window on a Linux host, it enables the use a variety of POSIX abstractions, such as mmap(), open() (via /dev/mem), read() and write(), to access the emulated ROM. xobs used these abstractions to create an I/O target for radare2. The I/O target automatically updates the SHA-1 hash every time we made changes in the 1bl code space, enabling us to do cute things like interactively patch and disassemble code within the emulated ROM space.

We also wired up the power switch of the phone to an FPGA I/O, so we could write automated scripts that toggle the power on the phone while updating the ROM contents, allowing us to do automated fuzzing of unknown hardware blocks.

Attaching a Debugger

Because of the difficulty in trying to locate critical blocks, and because JTAG is multiplexed with critical functions on the target device, an unconventional approach was taken to attach a debugger: xobs emulates the ARM core, and uses his fernly shell to reflect virtual loads and stores to the live target. This allows us to attach a remote debugger to the emulated core, bypassing the need for JTAG and allowing us to use cross-platform tools such as IDA on x86 for the reversing UI.

At the heart of this technique is Qemu, a multi-platform system emulator. It supports emulating ARM targets, specifically the ARMv5 used in the target device. A new machine type was created called “fernvale” that implements part of the observed hardware on the target, and simply passes unknown memory accesses directly to the device.

The Fernly shell was stripped down to only support three commands: write, read, and zero-memory. The write command pokes a byte, word, or dword into RAM on the live target, and a read command reads a byte, word, or dword from the live target. The zero-memory command is an optimization, as the operating system writes large quantities of zeroes across a large memory area.

In addition, the serial port registers are hooked and emulated, allowing a host system to display serial data as if it were printed on the target device. Finally, SPI, IRAM, and PSRAM are all emulated as they would appear on the real device. Other areas of memory are either trapped and funneled to the actual device, or are left unmapped and are reported as errors by Qemu.


The diagram above illustrates the architecture of the debugger.

Invoking the debugger is a multi-stage process. First, the actual MT6260 target is primed with the Fernly shell environment. Then, the Qemu virtual ARM CPU is “booted” using the original vendor image – or rather, primed with a known register state at a convenient point in the boot process. At this point, code execution proceeds on the virtual machine until a load or store is performed to an unknown address. Virtual machine execution is paused while a query is sent to the real MT6260 via the Fernly shell interface, and the load or store is executed on the real machine. The results of this load or store is then relayed to the virtual machine and execution is resumed. Of course, Fernly will crash if a store happens to land somewhere inside its memory footprint. Thus, we had to hide the Fernly shell code in a region of IRAM that’s trapped and emulated, so loads and stores don’t overwrite the shell code. Running Fernly directly out of the SPI ROM also doesn’t work as part of the initialization routine of the vendor binary modifies SPI ROM timings, causing SPI emulation to fail.

Emulating the target CPU allows us to attach a remote debugger (such as IDA) via GDB over TCP without needing to bother with JTAG. The debugger has complete control over the emulated CPU, and can access its emulated RAM. Furthermore, due to the architecture of qemu, if the debugger attempts to access any memory-mapped IO that is redirected to the real target, the debugger will be able to display live values in memory. In this way, the real target hardware is mostly idle, and is left running in the Fernly shell, while the virtual CPU performs all the work. The tight integration of this package with IDA-over-GDB also allows us to very quickly and dynamically execute subroutines and functions to confirm their purpose.

Below is an example of the output of the hybrid Qemu/live-target debug harness. You can see the trapped serial writes appearing on the console, plus a log of the writes and reads executed by the emulated ARM CPU, as they are relayed to the live target running the reduced Fernly shell.

bunnie@bunnie-novena-laptop:~/code/fernvale-qemu$ ./run.sh 

~~~ Welcome to MTK Bootloader V005 (since 2005) ~~~
**===================================================**

READ WORD Fernvale Live 0xa0010328 = 0x0000... ok
WRITE WORD Fernvale Live 0xa0010328 = 0x0800... ok
READ WORD Fernvale Live 0xa0010230 = 0x0001... ok
WRITE WORD Fernvale Live 0xa0010230 = 0x0001... ok
READ DWORD Fernvale Live 0xa0020c80 = 0x11111011... ok
WRITE DWORD Fernvale Live 0xa0020c80 = 0x11111011... ok
READ DWORD Fernvale Live 0xa0020c90 = 0x11111111... ok
WRITE DWORD Fernvale Live 0xa0020c90 = 0x11111111... ok
READ WORD Fernvale Live 0xa0020b10 = 0x3f34... ok
WRITE WORD Fernvale Live 0xa0020b10 = 0x3f34... ok

From this beachhead, we were able to discover the offsets of a few IP blocks that were re-used from previous known Mediatek chips (such as the MT6235 in the osmocomBB http://bb.osmocom.org/trac/wiki/MT6235) by searching for their “signature”. The signature ranged from things as simple as the power-on default register values, to changes in bit patterns due to the side effects of bit set/clear registers located at offsets within the IP block’s address space. Using this technique, we were able to find the register offsets of several peripherals.

Booting an OS

From here we were able to progress rapidly on many fronts, but our goal of a port of NuttX remained elusive because there was no documentation on the interrupt controller within the canon of Shanzhai datasheets. Although we were able to find the routines that installed the interrupt handlers through static analysis of the binaries, we were unable to determine the address offsets of the interrupt controller itself.

At this point, we had to open the Mediatek codebase and refer to the include file that contained the register offsets and bit definitions of the interrupt controller. We believe this is acceptable because facts are not copyrightable. Justice O’Connor wrote in Feist v. Rural (449 U.S. 340, 345, 349 (1991). See also Sony Computer Entm’t v. Connectix Corp., 203 F. 3d 596, 606 (9th Cir. 2000); Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510, 1522-23 (9th Cir. 1992)) that

“Common sense tells us that 100 uncopyrightable facts do not magically change their status when gathered together in one place. … The key to resolving the tension lies in understanding why facts are not copyrightable: The sine qua non of copyright is originality”

and

“Notwithstanding a valid copyright, a subsequent compiler remains free to use the facts contained in another’s publication to aid in preparing a competing work, so long as the competing work does not feature the same selection and arrangement”.

And so here, we must tread carefully: we must extract facts, and express them in our own selection and arrangement. Just as the facts that “John Doe’s phone number is 555-1212” and “John Doe’s address is 10 Main St.” is not copyrightable, we need to extract facts such as “The interrupt controller’s base address in 0xA0060000”, and “Bit 1 controls status reporting of the LCD” from the include files, and re-express them in our own header files.

The situation is further complicated by blocks for which we have absolutely no documentation, not even an explanation of what the registers mean or how the blocks function. For these blocks, we reduce their initialization into a list of address and data pairs, and express this in a custom scripting language called “scriptic”. We invented our own language to avoid subconscious plagiarism – it is too easy to read one piece of code and, from memory, code something almost exactly the same. By transforming the code into a new language, we’re forced to consider the facts presented and express them in an original arrangement.

Scriptic is basically a set of assembler macros, and the syntax is very simple. Here is an example of a scriptic script:

#include "scriptic.h"
#include "fernvale-pll.h"

sc_new "set_plls", 1, 0, 0

  sc_write16 0, 0, PLL_CTRL_CON2
  sc_write16 0, 0, PLL_CTRL_CON3
  sc_write16 0, 0, PLL_CTRL_CON0
  sc_usleep 1

  sc_write16 1, 1, PLL_CTRL_UPLL_CON0
  sc_write16 0x1840, 0, PLL_CTRL_EPLL_CON0
  sc_write16 0x100, 0x100, PLL_CTRL_EPLL_CON1
  sc_write16 1, 0, PLL_CTRL_MDDS_CON0
  sc_write16 1, 1, PLL_CTRL_MPLL_CON0
  sc_usleep 1

  sc_write16 1, 0, PLL_CTRL_EDDS_CON0
  sc_write16 1, 1, PLL_CTRL_EPLL_CON0
  sc_usleep 1

  sc_write16 0x4000, 0x4000, PLL_CTRL_CLK_CONDB
  sc_usleep 1

  sc_write32 0x8048, 0, PLL_CTRL_CLK_CONDC
  /* Run the SPI clock at 104 MHz */
  sc_write32 0xd002, 0, PLL_CTRL_CLK_CONDH
  sc_write32 0xb6a0, 0, PLL_CTRL_CLK_CONDC
  sc_end

This script initializes the PLL on the MT6260. To contrast, here’s the first few lines of the code snippet from which this was derived:

// enable HW mode TOPSM control and clock CG of PLL control 

*PLL_PLL_CON2 = 0x0000; // 0xA0170048, bit 12, 10 and 8 set to 0 to enable TOPSM control 
                        // bit 4, 2 and 0 set to 0 to enable clock CG of PLL control
*PLL_PLL_CON3 = 0x0000; // 0xA017004C, bit 12 set to 0 to enable TOPSM control

// enable delay control 
*PLL_PLLTD_CON0= 0x0000; //0x A0170700, bit 0 set to 0 to enable delay control

//wait for 3us for TOPSM and delay (HW) control signal stable
for(i = 0 ; i  loop_1us*3 ; i++);

//enable and reset UPLL
reg_val = *PLL_UPLL_CON0;
reg_val |= 0x0001;
*PLL_UPLL_CON0  = reg_val; // 0xA0170140, bit 0 set to 1 to enable UPLL and generate reset of UPLL

The original code actually goes on for pages and pages, and even this snippet is surrounded by conditional statements which we culled as they were not relevant facts to initializing the PLL correctly.

With this tool added to our armory, we were finally able to code sufficient functionality to boot NuttX on our own Fernvale hardware.

Toolchain

Requiring users to own a Novena ROMulator to hack on Fernvale isn't a scalable solution, and thus in order to round out the story, we had to create a complete developer toolchain. Fortunately, the compiler is fairly cut-and-dry – there are many compilers that support ARM as a target, including clang and gcc. However, flashing tools for the MT6260 are much more tricky, as all the existing ones that we know of are proprietary Windows programs, and Osmocom's loader doesn't support the protocol version required by the MT6260. Thus, we had to reverse engineer the Mediatek flashing protocol and write our own open-source tool.

Fortunately, a blank, unfused MT6260 shows up as /dev/ttyUSB0 when you plug it into a Linux host – in other words, it shows up as an emulated serial device over USB. This at least takes care of the lower-level details of sending and receiving bytes to the device, leaving us with the task of reverse engineering the protocol layer. xobs located the internal boot ROM of the MT6260 and performed static code analysis, which provided a lot of insight into the protocol. He also did some static analysis on Mediatek's Flashing tool and captured live traces using a USB protocol analyzer to clarify the remaining details. Below is a summary of the commands he extracted, as used in our open version of the USB flashing tool.

enum mtk_commands {
  mtk_cmd_old_write16 = 0xa1,
  mtk_cmd_old_read16 = 0xa2,
  mtk_checksum16 = 0xa4,
  mtk_remap_before_jump_to_da = 0xa7,
  mtk_jump_to_da = 0xa8,
  mtk_send_da = 0xad,
  mtk_jump_to_maui = 0xb7,
  mtk_get_version = 0xb8,
  mtk_close_usb_and_reset = 0xb9,
  mtk_cmd_new_read16 = 0xd0,
  mtk_cmd_new_read32 = 0xd1,
  mtk_cmd_new_write16 = 0xd2,
  mtk_cmd_new_write32 = 0xd4,
  // mtk_jump_to_da = 0xd5,
  mtk_jump_to_bl = 0xd6,
  mtk_get_sec_conf = 0xd8,
  mtk_send_cert = 0xe0,
  mtk_get_me = 0xe1, /* Responds with 22 bytes */
  mtk_send_auth = 0xe2,
  mtk_sla_flow = 0xe3,
  mtk_send_root_cert = 0xe5,
  mtk_do_security = 0xfe,
  mtk_firmware_version = 0xff,
};

Current Status and Summary

After about a year of on-and-off effort between work on the Novena and Chibitronics campaigns, we were able to boot a port of NuttX on the MT6260. A minimal set of hardware peripherals are currently supported; it’s enough for us to roughly reproduce the functionality of an AVR used in an Arduino-like context, but not much more. We’ve presented our results this year at 31C3 (slides).

The story takes an unexpected twist right around the time we were writing our CFP proposal for 31C3. The week before submission, we became aware that Mediatek released the LinkIT ONE, based on the MT2502A, in conjunction with Seeed Studios. The LinkIT ONE is directly aimed at providing an Internet of Things platform to entrepreneurs and individuals. It’s integrated into the Arduino framework, featuring an open API that enables the full functionality of the chip, including GSM functions. However, the core OS that boots on the MT2502A in the LinkIT ONE is still the proprietary Nucleus OS and one cannot gain direct access to the hardware; they must go through the API calls provided by the Arduino shim.

Realistically, it’s going to be a while before we can port a reasonable fraction of the MT6260’s features into the open source domain, and it’s quite possible we will never be able to do a blob-free implementation of the GSM call functions, as those are controlled by a DSP unit that’s even more obscure and undocumented. Thus, given the robust functionality of the LinkIT ONE compared to Fernvale, we’ve decided to leave it as an open question to the open source community as to whether or not there is value in continuing the effort to reverse engineer the MT6260: How important is it, in practice, to have a blob-free firmware?

Regardless of the answer, we released Fernvale because we think it’s imperative to exercise our fair use rights to reverse engineer and create interoperable, open source solutions. Rights tend to atrophy and get squeezed out by competing interests if they are not vigorously exercised; for decades engineers have sat on the sidelines and seen ever more expansive patent and copyright laws shrink their latitude to learn freely and to innovate. I am saddened that the formative tinkering I did as a child is no longer a legal option for the next generation of engineers. The rise of the Shanzhai and their amazing capabilities is a wake-up call. I see it as evidence that a permissive IP environment spurs innovation, especially at the grass-roots level. If more engineers become aware of their fair use rights, and exercise them vigorously and deliberately, perhaps this can catalyze a larger and much-needed reform of the patent and copyright system.

Want to read more? Check out xobs’ post on Fernvale. Want to get involved? Chime in at our forums. Or, watch the recording of our talk below.

Team Kosagi would like to once again extend a special thanks to .mudge for making this research possible.

by bunnie at December 28, 2014 09:00 PM

December 22, 2014

Richard Hughes, ColorHug

OpenHardware : Ambient Light Sensor

My OpenHardware post about an entropy source got loads of high quality comments, huge thanks to all who chimed in. There look to be a few existing projects producing OpenHardware, and the various comments have links to the better ones. I’ll put this idea back on the shelf for another holiday-hacking session. I’ve still not given up on the SD card interface, although it looks like emulating a storage device might be the easiest and quickest route for any future project.

So, on to the next idea. An OpenHardware USB ambient light sensor. A lot of hardware doesn’t have a way of testing the ambient light level. Webcams don’t count, they use up waaaay too much power and the auto-white balence is normally hardcoded in hardware. So I was thinking of producing a very low cost mini-dongle to measure the ambient light level so that lower-spec laptops could be saving tons of power. With smartphones people are now acutely aware than up to 60% of their battery power is just making the screen light up and I’m sure we could be smarter about what we do in GNOME. The problem traditionally, has been the lack of hardware with this support.

Anyone interested?

by hughsie at December 22, 2014 05:06 PM

December 21, 2014

ZeptoBARS

KR1818VG93 - FDD controller : weekend die-shot

Enthusiasts started yet another reverse engineering project of KR1818VG93 - FDD controller manufactured in USSR times. Presumably it has some compatibility/similarity with FDC1793-02 - this will be figured out.

Die size 4817x4794 µm, 6µm NMOS technology.



After stripping metal:

December 21, 2014 09:07 AM

December 19, 2014

Richard Hughes, ColorHug

OpenHardware Random Number Generator

Before I spend another night reading datasheets; would anyone be interested in an OpenHardware random number generator in an full-size SD card format? The idea being you insert the RNG into the SD slot of your laptop, leave it there, and the kernel module just slurps trusted entropy when required.

Why SD? It’s a port that a a lot of laptops already have empty, and on server class hardware you can just install a PCIe addon card. I think I can build such a thing for less than $50, but at the moment I’m just waiting for parts for a prototype so that’s really just a finger-in-the-air estimate. Are there enough free software people who care about entropy-related stuff?

by hughsie at December 19, 2014 05:06 PM

December 18, 2014

Bunnie Studios

Maker Pro: Soylent Supply Chain

A few editors have approached me about writing a book on manufacturing, but that’s a bit like asking an architect to take a photo of a building that’s still on the drawing board. The story is still unfolding; I feel as if I’m still fumbling in the dark trying to find my glasses. So, when Maker Media approached me to write a chapter for their upcoming “Maker Pro” book, I thought perhaps this was a good opportunity to make a small and manageable contribution.

The Maker Pro book is a compendium of vignettes written by 17 Makers, and you can pre-order the Maker Pro book at Amazon now.

Maker Media was kind enough to accommodate my request to license my contribution using CC BY-SA-3.0. As a result, I can share my chapter with you here. I titled it the “Soylent Supply Chain” and it’s about the importance of people and relationships when making physical goods.


Soylent Supply Chain

The convenience of modern retail and ecommerce belies the complexity of supply chains. With a few swipes on a tablet, consumers can purchase almost any household item and have it delivered the next day, without facing another human. Slick marketing videos of robots picking and packing components and CNCs milling components with robotic precision create the impression that everything behind the retail front is also just as easy as a few search queries, or a few well-worded emails. This notion is reinforced for engineers who primarily work in the domain of code; system engineers can download and build their universe from source–the FreeBSD system even implements a command known as ‘make buildworld’, which does exactly that.

The fiction of a highly automated world moving and manipulating atoms into products is pervasive. When introducing hardware startups to supply chains in practice, almost all of them remark on how much manual labor goes into supply chains. Only the very highest volume products and select portions of the supply chain are well-automated, a reality which causes many to ask me, “Can’t we do something to relieve all these laborers from such menial duty?” As menial as these duties may seem, in reality, the simplest tasks for humans are incredibly challenging for a robot. Any child can dig into a mixed box of toys and pick out a red 2×1 Lego brick, but to date, no robot exists that can perform this task as quickly or as flexibly as a human. For example, the KIVA Systems mobile-robotic fulfillment system for warehouse automation still requires humans to pick items out of self-moving shelves, and FANUC pick/pack/pal robots can deal with arbitrarily oriented goods, but only when they are homogeneous and laid out flat. The challenge of reaching into a box of random parts and producing the correct one, while being programmed via a simple voice command, is a topic of cutting-edge research.


bunnie working with a factory team. Photo credit: Andrew Huang.

The inverse of the situation is also true. A new hardware product that can be readily produced through fully automated mechanisms is, by definition, less novel than something which relies on processes not already in the canon of fully automated production processes. A laser-printed sheet will always seem more pedestrian than a piece of offset-printed, debossed, and metal-film transferred card stock. The mechanical engineering details of hardware are particularly refractory when it comes to automation; even tasks as simple as specifying colors still rely on the use of printed Pantone registries, not to mention specifying subtleties such as textures, surface finishes, and the hand-feel of buttons and knobs. Of course, any product’s production can be highly automated, but it requires a huge investment and thus must ship in volumes of millions per month to amortize the R&D cost of creating the automated assembly line.

Thus, supply chains are often made less of machines, and more of people. Because humans are an essential part of a supply chain, hardware makers looking to do something new and interesting oftentimes find that the biggest roadblock to their success isn’t money, machines, or material: it’s finding the right partners and people to implement their vision. Despite the advent of the Internet and robots, the supply chain experience is much farther away from Amazon.com or Target than most people would assume; it’s much closer to an open-air bazaar with thousands of vendors and no fixed prices, and in such situations getting the best price or quality for an item means building strong personal relationships with a network of vendors. When I first started out in hardware, I was ill-equipped to operate in the open-market paradigm. I grew up in a sheltered part of Midwest America, and I had always shopped at stores that had labeled prices. I was unfamiliar with bargaining. So, going to the electronics markets in Shenzhen was not only a learning experience for me technically, it also taught me a lot about negotiation and dealing with culturally different vendors. While it’s true that a lot of the goods in the market are rubbish, it’s much better to fail and learn on negotiations over a bag of LEDs for a hobby project, rather than to fail and learn on negotiations on contracts for manufacturing a core product.


One of bunnie’s projects is Novena, an open source laptop. Photo credit: Crowd Supply.

This point is often lost upon hardware startups. Very often I’m asked if it’s really necessary to go to Asia–why not just operate out of the US? Aren’t emails and conference calls good enough, or worst case, “can we hire an agent” who manages everything for us? I guess this is possible, but would you hire an agent to shop for dinner or buy clothes for you? The acquisition of material goods from markets is more than a matter of picking items from the shelf and putting them in a basket, even in developed countries with orderly markets and consumer protection laws. Judgment is required at all stages — when buying milk, perhaps you would sort through the bottles to pick the one with greatest shelf life, whereas an agent would simply grab the first bottle in sight. When buying clothes, you’ll check for fit, loose strings, and also observe other styles, trends, and discounted merchandise available on the shelf to optimize the value of your purchase. An agent operating on specific instructions will at best get you exactly what you want, but you’ll miss out better deals simply because you don’t know about them. At the end of the day, the freshness of milk or the fashion and fit of your clothes are minor details, but when producing at scale even the smallest detail is multiplied thousands, if not millions of times over.

More significant than the loss of operational intelligence, is the loss of a personal relationship with your supply chain when you surrender management to an agent or manage via emails and conference calls alone. To some extent, working with a factory is like being a houseguest. If you clean up after yourself, offer to help with the dishes, and fix things that are broken, you’ll always be welcome and receive better service the next time you stay. If you can get beyond the superficial rituals of politeness and create a deep and mutually beneficial relationship with your factory, the value to your business goes beyond money–intangibles such as punctuality, quality, and service are priceless.

I like to tell hardware startups that if the only value you can bring to a factory is money, you’re basically worthless to them–and even if you’re flush with cash from a round of financing, the factory knows as well as you do that your cash pool is finite. I’ve had folks in startups complain to me that in their previous experience at say, Apple, they would get a certain level of service, so how come we can’t get the same? The difference is that Apple has a hundred billion dollars in cash, and can pay for five-star service; their bank balance and solid sales revenue is all the top-tier contract manufacturers need to see in order to engage.


Circuit Stickers, adhesive-backed electronic components, is another of bunnie’s projects. Photo credit: Andrew “bunnie” Huang.

On the other hand, hardware startups have to hitchhike and couch-surf their way to success. As a result, it’s strongly recommended to find ways other than money to bring value to your partners, even if it’s as simple as a pleasant demeanor and an earnest smile. The same is true in any service industry, such as dining. If you can afford to eat at a three-star Michelin restaurant, you’ll always have fairy godmother service, but you’ll also have a $1,000 tab at the end of the meal. The local greasy spoon may only set you back ten bucks, but in order to get good service it helps to treat the wait staff respectfully, perhaps come at off-peak hours, and leave a good tip. Over time, the wait staff will come to recognize you and give you priority service.

At the end of the day, a supply chain is made out of people, and people aren’t always rational and sometimes make mistakes. However, people can also be inspired and taught, and will work tirelessly to achieve the goals and dreams they earnestly believe in: happiness is more than money, and happiness is something that everyone wants. For management, it’s important to sell your product to the factory, to get them to believe in your vision. For engineers, it’s important to value their effort and respect their skills; I’ve solved more difficult problems through camaraderie over beers than through PowerPoint in conference rooms. For rank-and-file workers, we try our best to design the product to minimize tedious steps, and we spend a substantial amount of effort making the tools we provide them for production and testing to be fun and engaging. Where we can’t do this, we add visual and audio cues that allow the worker to safely zone out while long and boring processes run. The secret to running an efficient hardware supply chain on a budget isn’t just knowing the cost of everything and issuing punctual and precise commands, but also understanding the people behind it and effectively reading their personalities, rewarding them with the incentives they actually desire, and guiding them to improve when they make mistakes. Your supply chain isn’t just a vendor; they are an extension of your own company.

Overall, I’ve found that 99% of the people I encounter in my supply chain are fundamentally good at heart, and have an earnest desire to do the right thing; most problems are not a result of malice, but rather incompetence, miscommunication, or cultural misalignment. Very significantly, people often live up to the expectations you place on them. If you expect them to be bad actors, even if they don’t start out that way, they have no incentive to be good if they are already paying the price of being bad — might as well commit the crime if you know you’ve been automatically judged as guilty with no recourse for innocence. Likewise, if you expect people to be good, oftentimes they will rise up and perform better simply because they don’t want to disappoint you, or more importantly, themselves. There is the 1% who are truly bad actors, and by nature they try to position themselves at the most inconvenient road blocks to your progress, but it’s important to remember that not everyone is out to get you. If you can gather a syndicate of friends large enough, even the bad actors can only do so much to harm you, because bad actors still rely upon the help of others to achieve their ends. When things go wrong your first instinct should not be “they’re screwing me, how do I screw them more,” but should be “how can we work together to improve the situation?”

In the end, building hardware is a fundamentally social exercise. Generally, most interesting and unique processes aren’t automated, and as such, you have to work with other people to develop bespoke processes and products. Furthermore, physical things are inevitably owned or operated upon by other people, and understanding how to motivate and compel them will make a difference in not only your bottom line, but also in your schedule, quality, and service level. Until we can all have Tony Stark’s JARVIS robot to intelligently and automatically handle hardware fabrication, any person contemplating manufacturing hardware at scale needs to understand not only circuits and mechanics, but also how to inspire and effectively command a network of suppliers and laborers.

After all, “it’s people — supply chains are made out of people!”

by bunnie at December 18, 2014 11:02 AM

Name that Ware December 2014

The Ware for December 2014 is shown below.

Thanks again to dmo and QB for letting me photograph this ware.

Happy holidays!

by bunnie at December 18, 2014 08:22 AM

Winner, Name that Ware November 2014

The Ware for November 2014 is a linear actuator for ulta-high vacuum environments, with a pass-through. You can actually download a spec for the ware at 真空機器・部品.com. Thanks again to dmo and QB for letting me snag a couple wares and use them for the competition.

Albert got the correct first guess about it being a linear actuator for UHV environments (but missed the pass-through part). I really like Arnuschky’s detailed explanation, and he also identified the pass-through feature, so I’ll declare him the winner. Congrats, thanks for playing!

by bunnie at December 18, 2014 08:21 AM

December 17, 2014

Richard Hughes, ColorHug

Actually shipping AppStream metadata in the repodata

For the last couple of releases Fedora has been shipping the appstream metadata in a package. First it was the gnome-software package, but this wasn’t an awesome dep for KDE applications like Apper and was a pain to keep updated. We then moved the data to an appstream-data package, but this was just as much of a hack that was slightly more palatable for KDE. What I’ve wanted for a long time is to actually ship the metadata as metadata, i.e. next to the other files like primary.xml.gz on the mirrors.

I’ve just pushed the final patches to libhif, PackageKit and appstream-glib, which that means if you ship metadata of type appstream and appstream-icons in repomd.xml then they get downloaded automatically and decompressed into the right place so that gnome-software and apper can use the data magically.

I had not worked on this much before, as appstream-builder (which actually produces the two AppStream files) wasn’t suitable for the Fedora builders for two reasons:

  • Even just processing the changed packages, it took a lot of CPU, memory, and thus time.
  • Downloading screenshots from random websites all over the internet wasn’t something that a build server can do.

So, createrepo_c and modifyrepo_c to the rescue. This is what I’m currently doing for the Utopia repo.

createrepo_c --no-database x86_64/
createrepo_c --no-database SRPMS/
modifyrepo_c					\
	--no-compress				\
	/tmp/asb-md/appstream.xml.gz		\
	x86_64/repodata/
modifyrepo_c					\
	--no-compress				\
	/tmp/asb-md/appstream-icons.tar.gz	\
	x86_64/repodata/

If you actually do want to create the metadata on the build server, this is what I use for Utopia:

appstream-builder			\
	--api-version=0.8		\
	--origin=utopia			\
	--cache-dir=/tmp/asb-cache	\
	--enable-hidpi			\
	--max-threads=4			\
	--min-icon-size=48		\
	--output-dir=/tmp/asb-md	\
	--packages-dir=x86_64/		\
	--temp-dir=/tmp/asb-icons	\
	--screenshot-uri=http://people.freedesktop.org/~hughsient/fedora/21/screenshots/

For Fedora, I’m going to suggest getting the data files from alt.fedoraproject.org during compose. It’s not ideal as it still needs a separate server to build them on (currently sitting in the corner of my office) but gets us a step closer to what we want. Comments, as always, welcome.

by hughsie at December 17, 2014 08:50 PM

November 28, 2014

Video Circuits

Gieskes 3TrinsRGB1

Gieskes has come out with a lovely little closed architecture video synthesizer with a small break out bread board which opens up the whole thing to more interesting exploitation. Beautiful stuff.
















http://gieskes.nl/instruments/?file=3TrinsRGB1

by Chris (noreply@blogger.com) at November 28, 2014 04:47 AM

November 27, 2014

Bunnie Studios

Name that Ware, November 2014

The Ware for November 2014 is shown below.

(No, it’s not my turkey baster. But happy Thanksgiving!)

Thanks to dmo & QB for allowing me to photograph this ware.

by bunnie at November 27, 2014 05:46 PM

Winner, Name that Ware October 2014

The Ware from October 2014 is the active element of an HP 4900A inkjet printhead. It’s a pretty neat example of a piece of silicon being used to manipulate liquids on a micro-scale to create macro-scale results.

The winner is Adrian for getting the first near-correct guess, although I really enjoyed Marcan’s detailed thoughts about the ware. Congrats, email me for your prize.

by bunnie at November 27, 2014 05:46 PM

Altus Metrum

keithp&#x27;s rocket blog: Black Friday 2014

Altus Metrum's 2014 Black Friday Event

BLACK FOREST, Colorado USA

Altus Metrum announces two special offers for "Black Friday" 2014.

We are pleased to announce that both TeleMetrum and TeleMega will be back in stock and available for shipment before the end of November. To celebrate this, any purchase of a TeleMetrum, TeleMega, or EasyMega board will include, free of charge, one each of our 160, 400, and 850 mAh Polymer Lithium Ion batteries and a free micro USB cable!

To celebrate NAR's addition of our 1.9 gram recording altimeter, MicroPeak, to the list of devices approved for use in contests and records, and help everyone get ready for NARAM 2015's altitude events, purchase 4 MicroPeak boards and we'll throw in a MicroPeak USB adapter for free!

These deals will be available from 00:00 Friday, 28 November 2014 through 23:59 Monday, 1 December, 2014. Only direct sales through our web store at http://shop.gag.com are included; no other discounts apply.

Find more information on all Altus Metrum products at http://altusmetrum.org.

Thank you for your continued support of Altus Metrum in 2014. We continue to work on more cool new products, and look forward to meeting many of you on various flight lines in 2015!

November 27, 2014 07:47 AM

November 25, 2014

OggStreamer

#oggstreamer – Repair Series 1 – channel not working / high gain

some weeks ago I had to exchange an OggStreamer because one channel was not working – the user Mike recorded the following video to demonstrate the problem:

If you watch the video closely you can see that the left channel is always amplifying the Audio with a very high gain – and only as he turns the gain up also the right channel appears – actually it is the right channel that is working correctly and the left has an error where it has a very high gain.

Looking at the schematics reveals that a connection error to the Potentiometer (which is in the Feedback loop) could cause such a high gain of the inverting amplifier:

highgain

So a loose connector is my first guess. My second guess would be a faulty potentiometer.

Lets take the device apart:

DSC00005DSC00006

gently push the whole assembly (top and pcb) out of the extruded alluminium case:

DSC00007

A quick look around and touching cables reveals the problem:

DSC00011

because I had a spare contact lying around i soldered on a new contact, but elsewise I could have recycled the orignial one:

DSC00012

Time to put everything to gether and check if it works:

 

DSC00013

both channels work now :) success.


by oggstreamer at November 25, 2014 12:26 PM

November 17, 2014

ZeptoBARS

Torex XC6206 - CMOS LDO : weekend die-shot

Torex XC6206 is a popular and really tiny CMOS LDO, especially if you compare it to older bipolar ones, which were magnitude larger. 250mA LDO in SOT-23 might be hard to believe at first.

Datasheet mentions "laser trimming" but we see voltage set via mask and 2 fuses for fine tuning. It is possible though that they have common values set in mask (like this 3.3V one) , and rare voltages laser trimmed.

Die size 500x356 µm, 500nm technology.



Etching off metals:



November 17, 2014 04:49 AM

November 10, 2014

ZeptoBARS

DIP 10Mhz Quartz oscillator based on Seiko NPC HA5022A3 : weekend die-shot

Seiko NPC HA5022A3 contains internal load capacitors, oscillator with amplitude limiting (for reduced power consumption) and optional frequency divider.
Die size 976x770 µm.

Quartz crystal is mounted on springs - in order to reduce impact of vibration on oscillation stability and to make it's damage less likely:


There is an oscillator IC soldered on the ceramic PCB, as well as 0.01uF power supply decoupling cap. It seems we need to go deeper:

November 10, 2014 02:32 AM

November 03, 2014

Video Circuits

Just Jam Barbican

Got some work in this thing, coming up soon, along with lots of other nice artists and musicians.
http://www.barbican.org.uk/music/event-detail.asp?ID=17052

by Chris (noreply@blogger.com) at November 03, 2014 11:20 AM

Peter Chamberlain

Peter C has uploaded some amazing work from earlier in his career.


by Chris (noreply@blogger.com) at November 03, 2014 11:16 AM

Analogue Video Workshop

So the Video Workshop went really well, we are planning to do more but I also have a bunch of other related projects going on at the moment, so if you want to host one send me an email and I am sure we could work something out. I currently have a diy sync-gen on the workbench and have been generating a lot of footage, theres nothing like meeting a bunch of people and getting them enthusiastic about video art to scare you into finishing some of your own work. Thanks to all who were involved in putting the workshop on including Encounters, Seeing Sound, Arnolfini and Bath Spa University.

oh yeah and one of the attendees wrote us a very nice review, which I think is a really kind thing I should do more often when I go to talks.
http://mydylarama.org.uk/spip.php?article252

Here are two shots of Alex's video synthesis lesson.

by Chris (noreply@blogger.com) at November 03, 2014 11:01 AM

Sismo VGA Box

Here is what looks like a simple VGA breakout box for eurorack standard synths, pretty fun way to get it to video synthesis, you could have something similar together in an afternoon and use any audio source as an input. http://www.sismo.net.br/vga-box-eurorack/ 



















by Chris (noreply@blogger.com) at November 03, 2014 10:31 AM

Secretcinemauk.blogspot.co.uk

And sometimes you find something you really shouldn't have missed 

"Secret Cinema was an email list that provided announcements of avant-garde & artists' film and video screenings in London. Secret Cinema ran from 2001-2011, and this blog covers events from 2006 onwards. Subscribers received information about more events than are listed on this website."

by Chris (noreply@blogger.com) at November 03, 2014 10:15 AM

November 02, 2014

Kristian Paul

Piaware statics

/srv/data/paginaweb/blog/Untitled.html
Got a cheap rasberry pi recentently. Since the httpd on it was not eating lot cpu cycles decided to run something else that will give use to my rtl-sdr as well. Is called pi aware [1]. So far got interesting ADS-B statics from my place [2]. Not bad.

As a side note use rtl-power as a passive radar could be another interesting option, just for the stats ;-).


[1] http://flightaware.com/adsb/piaware/
    https://github.com/flightaware/
[2] http://flightaware.com/adsb/stats/user/kristianpaul

November 02, 2014 05:00 AM

October 31, 2014

ZeptoBARS

BFR93 - BJT RF transistor : weekend die-shot

BFR93 is a popular, BJT npn RF transistor.
Die size 265x264 µm. Transistor itself occupy only small part of the die - it is impractical to cut smaller die, it is already almost a silicon cube:



October 31, 2014 10:06 PM

Free Electrons

Call for participation for the FOSDEM Embedded developer room

BrusselsThe FOSDEM is by far the largest and most vibrant open-source event in Europe. With 5000+ participants, 400+ talks in just two days, a completely free entrance with no registration required, and many topics covered, it has become over the years a major meeting event of open-source developers.

The 2015 edition will take on January 31 and February 1st in Brussels. Like most years, a specific track dedicated to embedded systems is on the schedule, called the “Embedded Developer Room”. A call for participation has been published, and proposals are expected by December, 1st.

It is worth mentioning that the scope of the FOSDEM Embedded Developer Room goes much beyond Embedded Linux: it covers all types of embedded systems, including micro-controller based development, fun hacking or do-it-yourself projects, and much more. Looking at last year’s schedule of the Embedded Devroom is a good way of getting a feeling of the topics that are covered.

Also, FOSDEM has many other tracks that can be interesting to embedded Linux developers: last year there was a track about Tracing and debugging, a track about Memory and Storage, a track about Hardware, a developer room about Graphics, etc.

So, save the date, and join FOSDEM 2015 in Brussels!

by Thomas Petazzoni at October 31, 2014 09:55 AM

October 30, 2014

Richard Hughes, ColorHug

appdata-tools is dead

PSA: If you’re using appdata-validate, please switch to appstream-util validate from the appstream-glib project. If you’re also using the M4 macro, just replace APPDATA_XML with APPSTREAM_XML. I’ll ship both the old binary and the old m4 file in appstream-glib for a little bit, but I’ll probably remove them again the next time we bump ABI. That is all. :)

by hughsie at October 30, 2014 02:53 PM

October 28, 2014

Free Electrons

Videos of XDC2014 and Kernel Recipes 2014

Recently, two interesting conferences took place in France: the X.org developer conference (in Bordeaux, October 8th-10th) and the Kernel Recipes conference (in Paris, September 25th-26th).

X.org Foundation logo

Kernel Recipes logo

Both conferences have now published videos and slides of the different talks:

  • for the XDC 2014 conference, they are available in the program page
  • for the Kernel Recipes conference, they are available from the schedule page

It also means that the video of the talk given by Free Electrons engineer Maxime Ripard about the support for Allwinner processors in the kernel is now available: video, slides.

by Thomas Petazzoni at October 28, 2014 08:54 PM

October 27, 2014

Free Electrons

Call for participation for the Embedded Linux Conference 2015

San Jose, CaliforniaThe Embedded Linux Conference Europe is just over that it’s already time to think about the Embedded Linux Conference 2015, which will take place on March 23-25 in San Jose, California.

The call for participation has been published recently, and interested speakers are invited to submit their proposals before January, 9th 2015. The notifications of whether your talk is accepted or not will be sent on January, 16th and the final schedule is planned to be published on January, 23th.

At Free Electrons, we really would like to encourage developers who are working on interesting embedded Linux related projects to submit a talk about what they are doing: talking about a specific open-source project, feedback on some experience doing an embedded Linux based product, etc. The scope of topics covered by the Embedded Linux Conference is fairly broad, so do not hesitate to submit a proposal. Giving a talk at this conference is really a great way of getting feedback about what you’re doing, raising awareness about a particular project or issue, and generally meeting other developers interested in similar topics.

It is worth mentioning that for those people whose talk is accepted, the entrance ticket is free. For hobbyists working on their own on open-source projects, the Linux Foundation also has the possibility of funding travel to the conference.

by Thomas Petazzoni at October 27, 2014 12:34 PM

ZeptoBARS

10Mhz Quartz SMD oscillator based on Seiko NPC SM5009 : weekend die-shot

Seiko NPC SM5009 contains internal load capacitors, oscillator with amplitude limiting (for reduced power consumption) and optional frequency divider.

Die size 1194x897 µm, 800nm technology.




October 27, 2014 04:59 AM

October 20, 2014

ZeptoBARS

OnSemi MMBT2222A - npn BJT transistor : weekend die-shot



Die size 343x343 µm. Comparing to NXP BC847B die area is 1.5x larger (0.118 vs 0.076mm²), but maximum continuous collector current is 6 times higher (600mA vs 100mA, SOT-23 in both cases). This huge increase in current per transistor area is achieved by shunting thin (=high-resistance) base layer with metal. High resistance of base layer is the limiting factor for maximum collector current in BC847B.

October 20, 2014 12:42 PM

NXP 2N7002 N-channel MOSFET : weekend die-shot


Die size 377x377 µm.

Hexagonal cells of TrenchMOS transistor has 4µm size.

October 20, 2014 06:01 AM

October 19, 2014

ZeptoBARS

Espressif ESP8266 WiFi-serial interface : weekend die-shot

Since August of 2014 internet is literally blown by WiFi-serial modules on new ESP8266 chip which are currently being sold for less than 4$. Chinese company Espressif managed to cram entire WiFi, TCP/IP and HTTP stack into on-chip memory, without external DRAM. Analog front-end requires minimal external components, all filters are internal. All this allowed them to offer extremely aggressive price. Chip has marking ESP8089, which is their more advanced 40nm product. Apparently, they only differ in bonding and ROM content.

Die size 2050x2169 µm, half of which is occupied by transceiver and PA, 25% - on-chip memory (rough size estimations are ~300KiB), and the rest is Xtensa LX106 CPU core and other digital logic.





Chinese engineers did an outstanding job here on finally making WiFi IoT devices cost effective. Let's hope Espressif will eventually open more internal chip information for amateurs and end users.

October 19, 2014 08:32 PM

October 18, 2014

Bunnie Studios

Name that Ware October 2014

The Ware for October 2014 is shown below.

Very busy with getting Novena ready for shipping, and Chibitronics is ramping into full holiday season production. And then this darn thing breaks! Well, at least I got pictures to share.

Have fun!

by bunnie at October 18, 2014 11:32 AM

Winner, Name that Ware September 2014

The Ware from September 2014 was a Totalphase Beagle USB 480. Gratz to Nick Ames for having the first correct guess, email me for your prize! Unfortunately, none of the claims on the FPGA identification were convincing enough for me to accept them without having to do a lot of legwork of my own to verify.

by bunnie at October 18, 2014 11:31 AM

October 15, 2014

Richard Hughes, ColorHug

GNOME Software and Fonts

A few people have asked me now “How do I make my font show up in GNOME Software” and until today my answer has been something along the lines of “mrrr, it’s complicated“.

What we used to do is treat each font file in a package as an application, and then try to merge them together using some metrics found in the font and 444 semi-automatically generated AppData files from a manually updated .csv file. This wasn’t ideal as fonts were being renamed, added and removed, which quickly made the .csv file obsolete. The summary and descriptions were not translated and hard to modify. We used the pre-0.6 format AppData files as the MetaInfo specification had not existed when this stuff was hacked up just in time for Fedora 20.

I’ve spent the better part of today making this a lot more sane, but in the process I’m going to need a bit of help from packagers in Fedora, and maybe even helpful upstreams. This are the notes of what I’ve got so far:

Font components are supersets of font faces, so we’d include fonts together that make a cohesive set, for instance,”SourceCode” would consist of “SoureCodePro“, “SourceSansPro-Regular” and “SourceSansPro-ExtraLight“. This is so the user can press one button and get a set of fonts, rather than having to install something new when they’re in the application designing something. Font components need a one line summary for GNOME Software and optionally a long description. The icon and screenshots are automatically generated.

So, what do you need to do if you maintain a package with a single font, or where all the fonts are shipped in the same (sub)package? Simply ship a file like this in /usr/share/appdata/Liberation.metainfo.xml like this:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright 2014 Your Name <you@domain> -->
<component type="font">
  <id>Liberation</id>
  <metadata_license>CC0-1.0</metadata_license>
  <name>Liberation</name>
  <summary>Open source versions of several commercial fonts</summary>
  <description>
    <p>
      The Liberation Fonts are intended to be replacements for Times New Roman,
      Arial, and Courier New.
    </p>
  </description>
  <update_contact>richard_at_hughsie_dot_com</updatecontact>
  <url type="homepage">http://fedorahosted.org/liberation-fonts/</url>
</component>

There can be up to 3 paragraphs of description, and the summary has to be just one line. Try to avoid too much technical content here, this is designed to be shown to end-users who probably don’t know what TTF means or what MSCoreFonts are.

It’s a little more tricky when there are multiple source tarballs for a font component, or when the font is split up into subpackages by a packager. In this case, each subpackage needs to ship something like this into /usr/share/appdata/LiberationSerif.metainfo.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright 2014 Your Name <you@domain> -->
<component type="font">
  <id>LiberationSerif</id>
  <metadata_license>CC0-1.0</metadata_license>
  <extends>Liberation</extends>
</component>

This won’t end up in the final metadata (or be visible) in the software center, but it will tell the metadata extractor that LiberationSerif should be merged into the Liberation component. All the automatically generated screenshots will be moved to the right place too.

Moving the metadata to font packages makes the process much more transparent, letting packagers write their own descriptions and actually influence how things show up in the software center. I’m happy to push some of my existing content from the .csv file upstream.

These MetaInfo files are not supposed to replace the existing fontconfig files, nor do I think they should be merged into one file or format. If your package just contains one font used internally, or where there is only partial coverage of the alphabet, I don’t think we want to show this in GNOME Software, and thus it doesn’t need any new MetaInfo files.

by hughsie at October 15, 2014 01:48 PM

October 08, 2014

Video Circuits

Why Not, Jim Sosnin (1980)

A recent upload by Jim Sosnin drawn to my attention by the ever vigilant Jeffrey 
http://www.australianmusiccentre.com.au/artist/sosnin-jim

"Video synthesis demo from 1980, realised using EMS Spectron video synth plus some homebrew gear. The audio was created in 1978 using 3 Transaudio synths linked together. This digital transfer via an old U-matic (3/4-inch format) VCR, repaired for the occasion, to retrieve original stereo audio (my more recent VHS copy had mono audio only)."

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

October 06, 2014

ZeptoBARS

Analog Devices AD558 - MIL-Spec 8-bit I²L DAC : weekend die-shot

Analog Devices AD558 is an 8-bit I²L DAC in ceramic package (MIL spec).

It is still an open question how this chip got into ex-USSR/Russia - anonymous reader left no comments on that (this smells like cold war...). It is not a secret that Russia had no extensive civilian IC assortment in manufacturing, hence all military IC's must have been designed and manufactured from scratch (i.e. all R&D, prototypes and masks must be paid by government). In such conditions providing all variety of domestic ICs is economically impossible, at least without government expenses comparable to whole world's expenses on IC R&D. So "temporary", "case-by-case" permit to use imported (both legitimately and not-so-legitimately) western ICs in military equipment "until domestic products are ready" is still here after 24 years despite numerous attempts to end this practice.

Die size 2713x2141 µm, 6µm manufacturing technology, trimming laser was leaving ~8µm diameter spots.


Oh, these rounded resistors are just beautiful... Autorouters in 2014, do you see this?
Note how amount of laser trimming on R-ladder is different for different bits.



PS. Could anyone share position of western engineers on plastic-vs-ceramic package for military/space-grade IC's? It appears modern plastic packages offer more benefits (like better G-shock/vibration reliability and obviously cost) without sacrificing anything (temperature range and moisture are less of a concern now, radiation was never a concern for a package).

October 06, 2014 09:52 PM

October 03, 2014

Bunnie Studios

Novena Update

It’s been four months since we finished Novena’s crowd funding campaign, and we’ve made a lot of progress since then. Since then, a team of people have been hard at work to make Novena a reality.

It takes many hands to build a product of this complexity, and we couldn’t do it without our dedicated and hard-working team at AQS. Above is a photo from the conference room where we did the T1 plastics review in Dongguan, China.

In this update, we’ll be discussing progress on the Casing, Electronics, Accessories, Firmware and the Community.


Case construction update
We’re very excited that the Novena cases we’re carrying around are now made of entirely production-process hardware — no more prototypes. A total of 10 injection molding tools, many of the family molds, have been opened so far; for comparison, a product like NeTV or chumby had perhaps 3-4 tools.

For those not familiar with injection molding, it’s a process whereby plastic is molded into a net shape from hot, high pressure liquid plastic forced into a cavity made out of hardened steel. The steel tool is a masterpiece of engineering in itself – it’s a water-cooled block weighing in at about a ton, capable of handling pressures found at the bottom of the Mariana Trench, and the internal surfaces are machined to tolerances better than the width of a human hair. And on top of that, it contains a clockwork of moving pieces, with dozens of ejector pins, sliders, lifters and parting surfaces coming apart and back together again smoothly over thousands of cycles. It’s amazing that these tools can be crafted in a couple of months, yet here we are.

With so much complexity involved, it’s no surprise that the tools require several iterations of refinement to get absolutely perfect. In tooling jargon, the iterations are referred to as T0, T1, T2…etc. You’re doing pretty good if you can go to full production at T2; we’re currently at T1 stage. The T1 plastics are 99% there, with a few issues relating to flow and knit lines, as well as a couple of spots where the plastic is warping during cooling or binding to the tool during ejection and causing some deformation. This manifests itself in a couple spots where the seams aren’t as tight as we’d like them to be in the case.

Most people have only seen products of finished tooling, so I thought I’d share what a pretty typical T0 shot looks like, particularly for a large and complex tool like the Novena case base part. Test shots like this are typically done in colors that highlight defects and/or the resin is available as scrap, hence the gray color. The final units will be black.

There’s a lot going on with this piece of plastic, so below is a visual guide to some of the artifacts.

In the green boxes are a set of “sink marks”. These happen when the opposite side of the plastic has a particularly thin or thick feature. These areas will cool faster or slower than the bulk of the plastic, causing these regions to pucker slightly and cause what looks like a bit of a shadow. It’s particularly noticeable on mirror-finish parts. In this case, the sink marks are due to the plastic underneath the nut bosses of the Peek array being much thinner than the surrounding plastic. The fix to this problem was to slightly thicken that region, reducing the overall internal clearance of the case by 0.8mm. Fortunately, I had designed in a little extra clearance margin to the case so this was possible.

The red arrow points to a “knit line”. This is a region where plastic flow meets within the tool. Plastic, as it is injected into the cavity, will tend to flow from one or more gates, and where the molten plastic meets itself, it will leave a hairline scar. It’s often located at points of symmetry between the gates where the plastic is injected (on this tool, there are four gates located underneath the spot where the rubber feet go — gates are considered cosmetically unattractive and thus they are strategically placed to hide their location).

The white feathery artifacts, as indicated by the orange arrow, are flow marks. In this case, it seems plastic was cooling a bit too quickly within the tool, causing these streaks. This problem can often be fixed by adjusting the injection pressure, cycle length, and temperature. This tweaking is done using test shots on the molding machine, with one parameter at a time tweaked, shot after shot, until its optimum point is found. This process can sometimes take hundreds of shots, creating a small hill of scrap plastic as a by-product.

Most of these gross defects were fixed by T1, and the plastic now looks much closer to production-grade (and the color is now black). Below is the T1 shot in initial testing after transferring live hardware into the plastics.

There’s still a few issues around fit and finish. The rear lip is binding to the tool slightly during ejection, which is causing a little bit of deformation. Also, the panel we added at the last minute to accommodate oversized expansion boards isn’t mating as tightly as we’d like it to. But, despite all of these issues, the case feels much more solid than the prototypes, and the gas piston mechanism is finally consistent and really smooth.

Front bezel update
The front bezel of Novena’s case (not to be confused with the aluminum LCD bezel) has gone through a couple of changes since the campaign. When we closed funding, it had two outward-facing USB ports and one switch. Now, it has two switches and one outward-facing USB port and one inward-facing USB port.

One switch is for power — it goes directly to the power board and thus can be used to turn the system on and off even when the main board is fully powered down.

The other switch is wired to a user key press, and the intent is to facilitate Bluetooth association for keyboards that are being stupid. It seems some keyboards can take up to a half-minute to cycle through — something (presumably, it’s trying to be secure) — before they connect. There are hacks you can do to bypass that, but it requires you to run a script on the host, and the idea is by pressing this button users can trigger a convenience script to get past the utter folly of Bluetooth. This switch also doubles as a wake-up button for when the system is in suspend.

As for the USB ports, there are still four ports total in the design, but the configuration is now as follows:

  • Two higher-current capable ports on the right
  • One standard-current capable port on the front
  • One standard-current capable port facing toward the Peek Array
  • In other words, we face one USB port toward the inside of the machine; since half the fun of Novena is modding the hardware, we figure making a USB port available on the inside is at least as useful as making it available on the outside.

    For those who don’t do hardware mods, it’s also a fine place to plug small dongles that you generally keep permanently attached, such as a radio transceiver for your keyboard. It’s a little inconvenient to initially plug in the dongle, but keeping the radio transceiver dongle facing the inside helps protect it from damage when you throw your laptop into your travel bag.

    Speakers
    We toyed with several iterations of speaker selection for Novena. One of the core ideas behind the design was to make speaker choice something every user would be encouraged to make on their own. One driving reason for this is some people really listen to music on their laptop when they travel, but others simply rely upon the speaker for notification tones and would prefer to use headphones for media capabilities.

    Physics dictates that high-quality sound requires a certain amount of space and mass, and so users who have a more relaxed fidelity requirement should be able to reclaim the space and weight that nicer speakers would require.

    Kurt Mottweiler, the designer of the Heirloom model, had selected a nice but very compact off-the-shelf speaker, the PUI ASE06008MR-LW150-R, for the Heirloom. We evaluated that in the context of the standard Novena model and found that it fit well into the Peek Array and it also had acceptable fidelity, particularly for its size. And so, we adopted this as the standard offering for audio. However, it will be provided with a mounting kit that allows for easy removal so users who need to reclaim the space they take, or who want to go the other way and put in larger speakers, can do so with ease.


    PVT2 Mainboard
    The Novena mainboard went through a minor revision prior to mass production. The 21-point change list can be viewed here; the majority of the changes focused on replacing or updating components that were at risk of EOL. The two most significant changes from a design standpoint were the addition of an internal FPC header to connect to the front bezel cluster, and a dedicated hardware RTC module.

    The internal FPC header was added to improve the routing of signals from the mainboard to the front bezel cluster. We had to run two USB ports, plus a smattering of GPIOs and power to the front bezel and the original scheme required multiple cables to execute the connection. The updated design condenses all of this into a single FPC, thereby simplifying the design and improving reliability.

    A dedicated hardware RTC module was added because we couldn’t get the RTC built into the i.MX6 to perform well. It seems that the CPU simply had a higher leakage on the RTC than reported in the datasheet, and thus the lifetime of the RTC when the system was turned off was measured in, at best, minutes. We made the call that there was too much risk in continuing to develop with the on-board RTC and opted to include an external, dedicated RTC module that we knew would work. In order to increase compatibility with other i.MX6 platforms, we picked the same module used by the Solid-Run Hummingboard, the NXP PCF8523T/1.

    GPBB
    The GPBB got a face-lift and a couple of small mods to make it more hacker-friendly.

    I think everything looks a little bit nicer in matte black, so where it doesn’t compromise production integrity we opted to use a matte black soldermask with gold finish.

    Beyond the obvious cosmetic change, the GPBB also features an adjustable I/O voltage for the digital outputs. The design change is still going through testing, but the concept is to by default allow a 5V/3.3V selectable setting in software. However, the lower voltage can also be adjusted to 2.5V and 1.8V by changing a single resistor (R12), which I also labelled “I/O VOLTAGE SET” and made a 1206 part so soldering novices can make the change themselves.

    In our experience, we’re finding an ever-increasing gulf between the voltage standards used by hobbyists and what we’re actually finding inside equipment we need to reverse engineer; and thus, to accommodate both applications a flexible voltage output selection mechanism was added to the GPBB.

    Desktop Passthrough
    The desktop case originally included just the Novena mainboard, and the front panel breakout. It turns out this makes power management awkward, as the overall power management system for the case was designed with the assumption there is a helper microcontroller managing a master cut-off switch.

    Complexity is the devil, and it’s been hard enough to get the software going for even a single configuration. So in net we found it would be cheaper to introduce a new piece of hardware rather than deal with multiple code configurations.

    Therefore, desktop systems are now getting a power pass-through board as part of the offering. It’s a simple PCBA that contains just the STM32 controller and power switch of the full Senoko board. This allows us to use a consistent gross power management architecture across both the desktop and the laptop systems.

    Of course, this is swatting a fly with a sledgehammer, but this sledgehammer costs as much as the flyswatter and it’s inconvenient to carry both a fly swatter and a sledgehammer around. And so yes, we’re using a 32-bit ARM CPU to read the state of a pushbutton and flip a GPIO, and yes, this is all done using a full multi-threaded real time operating system (ChibiOS) running underneath it. It feels a little silly, which is why we broke out some of the unused GPIOs so there’s a chance some clever user might find an application for all that untapped power.


    Battery
    The battery pack for Novena is and will continue to be a wildcard in the stack. It’s our first time building a system with such a high-capacity battery, and working through all the shipping regulations to get these delivered to your front door will be a challenge.

    Some countries are particularly difficult in terms of their regulations around the importation of lithium batteries. In the worst case, we’ll send your laptop with no battery inside, and we will ship separately, at our cost, an off-the-shelf battery pack from a vendor that specializes in RC battery packs (e.g. Hobby King). You will have the same battery we featured in the crowd funding campaign, but you’ll need to plug it in yourself. We consider this to be a safe fall-back solution, since Hobby King ships thousands of battery packs a day all around the world.

    However, this did not stop us from developing a custom battery pack. As it’s very difficult to maintain a standing stock of battery packs (they need to be periodically conditioned), we’re including this custom battery pack only to backers of the campaign, providing their country of residence allows its import (and we won’t know for sure until we try). We did get UN38.3 certification for the custom battery pack, which in theory allows it to be shipped by air freight, but regulations around this are in flux. It seems countries and carriers keep on inventing new rules, particularly with all the paranoia about the potential use of lithium batteries as incendiary devices, and we don’t have the resources to keep up with the zeitgeist.

    For those who live in countries that allow the importation of our custom pack, the new pack features a 5000mAh rated capacity (about 2x the capacity over the pack we featured in the crowd campaign, which had 3000mAh printed on the outside but actually delivered about 2500mAh in practice). In real-life testing, the custom pack is getting about 6-7 hours of runtime with minimal power management enabled. Also, since I got to specify the battery, I know this one has the correct protection circuitry built into it, and I know the provenance of its cells and so I have a little more confidence in its long-term performance and stability.

    Of course, it’s a whole different matter convincing the lawmakers, customs authorities, and regulatory authorities of those facts…but fear not, even if they won’t accept this custom limited-edition battery, you will still get the original off-the-shelf pack promised in the campaign.

    Hard Drive
    In the campaign, we referenced providing 240GiB Intel 530 (or equivalent) and 480GiB Intel 720 drives for the laptop and heirloom models, respectively. We left the spec slightly ambiguous because the SSD market moves quickly, and probably the best drive last February when we drew up the spec will be different from the best drive we could get in October, when we actually do the purchasing.

    After doing some research, it’s our belief that the best equivalent drives today are the 240GiB Samsung 840 EVO (for the laptop model) and the 512GiB Samsung 850 Pro (for the Heirloom). We’ve been personally using the 840 EVO in our units for several months now, and they have performed admirably. An important metric for us is how well the drives hold up under unexpected power outages — this happens fairly often, for example, when you’re doing development work on the power management subsystem. Some hard drives, such as the SanDisk Extreme II, fail quite reliably (how’s that for an oxymoron) after a few unexpected power-down cycles. We’ve also had bad luck with OCZ and Crucial drives in the past.

    Intel drives have generally been pretty good, except that Intel stopped doing their own controllers for the 520 and 530 series and instead started using SandForce controllers, which in my opinion removes any potential advantage they could have being both the maker of the memory chips and the maker of the controller. The details of how flash memory performs, degrades, and yields are extremely process-specific, and at least in my fantasy world a company that produces flash + controller combinations should have an advantage over companies that have to mix-and-match multiple flash types with a semi-generic controller. Furthermore, while the Intel 720 does use their home-grown controller solution, it’s a power hog (over 5W active power) and requires a 12V rail, and is thus not suitable for use in laptop environments.

    The 840 EVO series comes with a reasonable 3-year warranty and at it’s held up well against one site’s write endurance test. After using mine for several months, I’ve had no complaints about it, and I think it’s a solid every-day use drive for firmware development. We also have a web server that hosts most of the media content for this and a couple other blogs, wikis, and bug tracking tools, and it’s a Novena running off an 840 EVO.

    For the premium Heirloom users, we’re very excited to build in the 850 PRO series. This drive comes with a serious warranty that matches the “heirloom” name — 10 years. The reason behind their ability to offer such a high claim of reliability is even more remarkable. The drive uses a technology that Samsung has branded “V-NAND”, which I consider to be the first bona-fide production-grade 3D transistor technology. Intel claims they make 3D transistors, but that’s just marketing hype — yes, the gate region has a raised surface topology, but you still only get a single layer of devices. From a design standpoint you’re still working with a 2D graph of devices. It’s like calling Braille a revolutionary 3D printing technology. The should have stuck with what I consider to be the “original” (and more descriptive/less misleading) name, FinFET, because by calling these 3D transistors I don’t know what they’re going to call actual 3D arrays of transistors, if they ever get around to making them.

    Chipworks did an excellent initial analysis of Samsung’s V-NAND technology and you can see from this SEM image they published that V-NAND isn’t about stacking just a couple transistors, Samsung is shipping a full-on 38-layer sandwich:

    This isn’t some lame Intel-style bra-padding exercise. This is full-on process technology bad-assery at its finest. This is Neo decoding the Matrix. This is Mal shooting first. It’s a stack of almost 40 individual, active transistors in a single spot. It’s a game changer, and it’s not vapor ware. Heirloom backers will get a laptop with over 4 trillion of these transistors packed inside, and it will be awesome.

    Sorry, I get excited about these kinds of things.


    Firmware
    From the software side, we’re working on finalizing the kernel, bootloader, and distro selection, as well as deciding what you’ll see when you first power on Novena.

    Marek Vasut is working on getting Novena supported in mainline U-Boot, which involves a surprising number of patches. Few ARM boards support as much RAM as Novena, so some support patches were needed first. Full support is in progress, including USB and video.

    We intend to ship with a mainline kernel, but interestingly Jon Nettleson has a 3.14 long-term-support kernel that is a hybrid of Freescale’s chip-specific patches combined with many backported upstream patches. Users may be interested in using this kernel over the upstream one, which has better support for thermal events and for power management.

    While we prefer to go with an upstream kernel, and to get our changes pushed into mainline, other users might find this kernel’s interesting blend of community and vendor code to satisfy their needs better.

    The kernel that we’ll use has most of the important parts upstreamed, including the audio chip which should be part of the 3.17 kernel. We’re still carrying a few local patches for various reasons ranging from specialized hacks to experimental features, or features that are not yet ready to push upstream, or rely on other features that are not yet upstream.

    For example, the display system on a laptop is very different from what is usually found on an ARM device, and we have local patches to fix this up. In most ARM devices, the screen is fixed during boot and it isn’t possible to hot-swap displays at runtime. Novena supports two different displays at once, and allows you to plug in an HDMI monitor without needing to reboot.

    Speaking of displays, the community has been hard at work on an accelerated 2D Xorg DDX driver. 2D acceleration is important, because most of the time users are interacting with the desktop, and 2D hardware uses significantly less power than 3D hardware. On a desktop machine, the 3D chip is used to composite the desktop. On Novena, which doesn’t have a fan and a small overall active power footprint, saving power is very important. By taking advantage of the 2D-only hardware, we save power while having a smoother experience. There are a few bugs that remain with the 2D driver, but it should be ready by the time we ship.

    There is a 3D driver that is in progress as well. It’s able to run Quake 3 on the framebuffer, but still has to be integrated into an OpenGL ES driver before it works under X.

    We’ve also been working on getting a root filesystem setup. This includes deciding which packages are installed, and customizing the list of software repositories. We want to add a repository for our kernel and bootloader, as well as for various packages which haven’t made it upstream such as an imx6 version of irqbalance. This will allow us to provide you with updated kernels as we add more support.

    Finally, the question remains of what you’ll see when you first power it up. In Linux, it’s not at all common to have a first-boot setup screen where you create your user, set the time, and configure the network. That’s common in Windows and OS X, which come preinstalled, but under Linux that’s generally taken care of by the installer. As we mull the topic, we’re torn between creating a good desktop-style experience vs. making a practical embedded developer’s experience. A desktop-style experience would ship a blank-slate and prompt the user to create an account via a locally attached keyboard and monitor; however, embedded developers may never plug a monitor into their device, and instead prefer to connect via console or ssh, thereby requiring a default username, password and hostname. Either way, we want to create just a single firmware common across all platforms, and so special-casing releases to a particular target is the least desired solution. If you have an opinion, please share it in our user forum.


    Community
    We’re pleased to see that even before shipping, we have a few alpha developers who continue to be very active. In addition to Jon Nettleton (gfx), Russell King (also gfx), and Marek Vasut (u-boot), we have a couple of other alpha user’s efforts we’d like to highlight in this update.

    MyriadRF continues to move forward with their SDR solution for Novena. About three weeks ago they sent us pre-production boards, and they are looking good. We’ve placed a binding order for their boards, and things look on track to get them into our shop by November, in time for integration with the first desktop units we’ll be shipping. MyriadRF is working on a fun demo for their hardware, but I’ll save that story for them to tell :)

    The CrypTech group has also been developing applications with the help of Novena. The CrypTech project is developing a BSD / CC BY-SA 3.0 licensed reference design and prototype examples of a Hardware Security Module. Their hope is to create a widely reviewed, designed-for-crypto device that anyone can compose for their application and easily build with their own trusted supply chain. They are using Novena to prototype elements of their design.

    The expansion board highlighted above is a prototype noise source based on avalanche noise from the transistor that can be seen on the middle of the board. CrypTech uses that noise to generate entropy in the FPGA. The entropy is then combined with entropy generated by ring oscillators in the FPGA and mixed using e.g. SHA-512 to generate seeds. The seeds are then used to initialize the ChaCha stream cipher, ultimately resulting in a stream of cryptographically sound random values. The result is a high performance, state-of-the art random number generator coprocessor. This of course represents just a first draft; since the implementation is done in an FPGA, the CrypTech team will continue to evolve their methodology and experiment with alternative methods to generate a robust stream of random numbers.

    Thanks to the CrypTech team for sharing a sneak-peek of their baby!

    Looking Forward

    From our current progress, it seems we’re still largely on track to release an initial shipment of bare boards to early backers in late November, and have an initial shipment of desktop units ready to go by late December. We’ll be shipping the units in tranches, so some backers will receive units before others.

    Our shipping algorithm is roughly a combination of how early someone backed the campaign, modified by which region of the world you’re in. As every country has different customs issues, we will probably ship just one or two items to each unique country first to uncover any customs or regulatory problems, before attempting to ship in bulk. This means backers outside the United States (where Crowd Supply’s fulfillment center is located) will be receiving their units a bit later than those within the US.

    And as a final note, if there’s one thing we’ve learned in the hardware business, is that you can’t count your chickens before they’ve hatched. Good progress to date doesn’t mean we’ve got an easy path to finished units. We still have a lot of hills to climb and rivers to cross, but at least for now we seem to be on track.

    Thanks again to all of our Novena backers, we’re looking forward to getting hardware into your hands soon!

    -bunnie & xobs

    by bunnie at October 03, 2014 06:15 PM

    October 01, 2014

    Free Electrons

    Actus trimestrielles: janvier 2013

    Cet article a été publié sur notre bulletin trimestriel d’information.

    Toute l’équipe de Free Electrons vous souhaite une bonne année 2013, avec tout le succès que vous attendez dans vos projets personnels et professionnels, et dans vos contributions à la vie d’autrui. Nous saisissons cette occasion pour vous donner des nouvelles de Free Electrons.

    En 2012, Free Electrons a continué à travailler sur des projets de développement. La principale différence avec 2011 est que les projets ont été bien plus longs. En voici les plus importants:

    • Développement de code pour le noyau Linux, pour prendre en charge les processeurs Armada 370 et Armada XP de Marvell dans le noyau Linux officiel. Cela représente des mois d’ingénierie ! Les modifications que nous avons apportées apparaissent sur git.kernel.org.
    • Développement de code pour le noyau Linux et mise en place d’un environnement de développement pour un nouveau système à base d’i.MX28 conçu par Crystalfontz, en ajoutant le support de cette carte à la version officielle de Linux. Vous trouverez plus de détails sur la page du projet sur Kickstarter !
    • Mise en place d’un système de compilation, développement de code de chargeur de démarrage et de pilotes noyau, amélioration du mécanisme de mise à jour, et plus généralement travail de développement de système Linux embarqué.
    • Développement de code noyau pour les convertisseurs analogique-numérique des processeurs AT91 d’Atmel, et inclusion dans les sources officielles du noyau.
    • Réduction du temps de démarrage et audit de gestion de l’énergie pour un terminal de paiement à base de processeur MIPS.
    • Réduction du temps de démarrage sur une plateforme de développement à base de processeur ARM pour terminal de paiement.
    • Développement, intégration, et support d’un système Linux embarqué

    Que ce soit à travers des contrats ou des contributions directes, 2012 nous a donné de nombreuses occasions de contribuer à des projets open-source, en particulier:

    • 195 patches inclus dans le noyau Linux, sans compter ceux qui ont été acceptés par les mainteneurs mais n’apparaissent pas encore dans la version de Linus Torvalds. Voir git.kernel.org pour plus de détails.
    • 448 patches inclus dans le système compilation Buildroot: détails sur git.buildroot.net.
    • 9 patches inclus dans le chargeur de démarrage U-boot.
    • 7 patches pour le chargeur de démarrage Barebox: détails sur git.penguntronix.de.

    Au passage, voici la commande git que vous pouvez lancer dans les dépôts correspondants pour obtenir ces mesures par vous-mêmes:

    git shortlog --no-merges -sn --author "free-electrons.com" --since="01/01/2012" --until="12/31/2012"
    

    Nous avons également donné de multiples sessions de nos formations Linux embarqué et développement de pilotes de périphériques noyau Linux. Nous avons également fini de migrer nos supports de formation du format Open Document vers LaTeX, et leurs sources sont maintenant disponibles sur notre dépôt git public. Cela devient beaucoup plus simple de suivre les changements et de soumettre des contributions.

    Nous avons également créé une nouvelle formation sur le développement système avec Android, et avons donné de multiples sessions chez nos clients ainsi qu’en session inter-entreprises à Toulouse. Il s’agit d’un programme de quatre jours, pour comprendre l’architecture du système Android, comment compiler et personnaliser le système pour une plateforme matérielle particulière, et comment l’étendre pour prendre en charge de nouveaux périphériques.

    Tout comme l’an passé, nous avons partagé notre expérience lors de conférences techniques internationales:

    En participant à ces conférences, nous avons également enregistré et publié des vidéos des présentations:

    Grâce à leurs contributions au noyau Linux official sur la plateforme ARM, Grégory Clément et Thomas Petazzoni ont également été invités au minisummit ARM au Linux Kernel Summit à San Jose en août. Ils ont été impliqués dans les décisions techniques sur les prochaines évolutions du noyau Linux sur l’architecture ARM.

    Nous avons aussi organisé et à participé à deux événements « Buildroot developer days », un à Bruxelles après le FOSDEM, et le deuxième à Barcelone après ELC Europe.

    Nous avons également continué à participer au développement de la communauté de Linaro, une société d’ingénierie à but non lucratif dont le but est l’amélioration de Linux sur la plateforme ARM. Cet engagement est arrivé à son terme, et ceci permet à Michael Opdenacker de reprendre des projets plus techniques.

    Il est maintenant temps de partager nos projets pour 2013.

    Nous avons prévu de recruter de nouveaux ingénieurs pour satisfaire une demande toujours croissante pour nos services de développement et de formation. En particulier, un nouvel ingénieur nous rejoint en mars.

    Nous organisons également de nouvelles sessions de formation inter-entreprises en France, dont les dates sont maintenant disponibles:

    Nous prévoyons également d’annoncer plusieurs nouvelles formations. Étant très pris par des projets en 2012, nous n’avons pas eu le temps d’avancer dans les objectifs que nous avions annoncés il y a un an:

    • Formation Git. Une formation de deux jours pour bien maîtriser l’utilisation du système de gestion de sources distribué Git, que ce soit pour des projets internes ou pour contribuer à des projets open-source.
    • Formation sur le débogage, le traçage et l’analyse de performance sur le noyau Linux. Une session d’une ou deux journées pour tracer l’exécution des fonctions du noyau, et pouvoir rechercher les causes de dysfonctionnements et de problèmes de performance.
    • Formation sur la réduction du temps de démarrage. Une formation d’une ou deux journées pour apprendre et maîtriser la méthodologie et les techniques pour faire démarrer plus vite vos systèmes Linux embarqué.

    Comme nous ne sommes qu’aux premières étapes de la préparation de ces formations, n’hésitez pas à saisir l’occasion de nous contacter et de nous faire part de vos attentes, pour influer sur leur contenu final, au cas où vous seriez intéressés par de telles formations.

    Nous continuerons également à participer aux conférences techniques les plus importantes. En particulier, les ingénieurs de Free Electrons seront présents à l’Android Builders Summit et à l’Embedded Linux Conference à San Francisco, ainsi qu’à l’Embedded Linux Conference Europe à Edinbourg en octobre. Cette participation aux conférences permet à nos ingénieurs de rester au courant des derniers développements dans le domaine de Linux embarqué et de créer des contacts utiles dans la communauté. N’hésitez pas à vous rendre ces conférences, pour développer vos connaissances techniques et pourquoi pas en profiter pour nous rencontrer !

    Enfin, nous ferons aussi plus d’efforts pour publier ce bulletin vraiment chaque trimestre. En 2012, nous étions si occupés par nos projets que nous n’avons pas réussi à publier de bulletins pour les troisième et quatrième trimestres.

    Vous pouvez continuer à suivre les actualités de Free Electrons en lisant notre blog en anglais (31 articles en 2012), nos actualités francophones et en suivant nos nouvelles brèves sur Twitter.

    Une fois de plus, bonne année 2013 !

    L’équipe de Free Electrons.

    by Michael Opdenacker at October 01, 2014 03:14 AM

    September 29, 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 September 29, 2014 02:30 PM

    Richard Hughes, ColorHug

    Shipping larger application icons in Fedora 22

    In GNOME 3.14 we show any valid application in the software center with an application icon of 32×32 or larger. Currently a 32×32 icon has to be padded with 16 pixels of whitespace on all 4 edges, and also has to be scaled x2 to match other UI elements on HiDPI screens. This looks very fuzzy and out of place and lowers the quality of an otherwise beautiful installing experience.

    For GNOME 3.16 (Fedora 22) we are planning to increase the minimum icon size to 48×48, with recommended installed sizes of 16×16, 24×24, 32×32, 48×48 and 256×256 (or SVG in some cases). Modern desktop applications typically ship multiple sizes of icons in known locations, and it’s very much the minority of applications that only ship one small icon.

    Soon I’m going to start nagging upstream maintainers to install larger icons than 32×32. If you’re re-doing the icon, please generate a 256×256 or 64×64 icon with alpha channel, as the latter will probably be the minimum size for F23 and beyond.

    At the end of November I’ll change the minimum icon size in the AppStream generator used for Fedora so that applications not fixed will be dropped from the metadata. You can of course install the applications manually on the command line, but they won’t be visible in the software center until they are installed.

    If you’re unclear on what needs to be done in order to be listed in the AppStream metadata, refer to the guidelines or send me email.

    by hughsie at September 29, 2014 11:59 AM

    September 28, 2014

    Bunnie Studios

    Name that Ware, September 2014

    The Ware for September 2014 is shown below.

    This months ware has a little bit of a story behind it, so I’ll give you this much about it to set up the story: it’s a USB protocol analyzer of some sort. Question is, what make and model?

    Now for the story.

    Name that ware is typically about things that cross my desk and get opened for one reason or the other — sometimes simply curiosity, sometimes more than that. This is a case where it was more than curiosity.

    Turns out this analyzer broke at an inopportune moment. Xobs was working on a high-priority reverse engineering task that required some USB analysis. Unfortunately, when we plugged in the analyzer, it just reported a series of connect/disconnect events but no data. We initially suspected a driver issue, but after connecting the analyzer to a previously known good configuration, we suspected a hardware failure.

    So, it was time to take the unit apart and figure out how to repair it. Of course, this is a closed-source device (still eagerly anticipating my OpenVizsla) so there are no schematics available. No worries; you’ll often hear me make the claim that it’s impossible to close hardware because you can just read a circuit board and figure out what’s going on. This particular ware was certainly amenable to that, as the construction is a four-layer board with a relatively simple assortment of chips on one side only.

    The USB analysis front-end consists of three major types of chip, outlined below.

    The chips in the red boxes are a pair of LMH6559 1.75GHz bandwidth amplifiers. Fortunately the top marking, “B05A”, was resolvable with a google search plus a few educated guesses as to the function of the chips. The chip in the yellow box is a Fairchild USB1T11A, a full-speed USB transceiver. And the chip in the green outline box is a Microchip (formerly SMSC) USB3300, a high-speed USB to ULPI transceiver. A casual read of the four-layer PCB indicates that the USB signal is passed through from the B-type port to the A-type port, with the LMH6559 acting as buffers to reduce loading, plus a resistor network of some type to isolate the USB1T11A. We figured that the most likely cause of the issue was electrical overstress on the LMH6559′s, since they lay naked to the USB port and quite possibly we could have shorted the data wires to a high voltage at some point in time, thereby damaging the buffers. We did a couple of quick tests and became semi-convinced that these were actually working just fine.

    Most likely the issue wasn’t the USB1T11A; it’s well-isolated. So the next candidate was the USB3300. Fortunately these were in stock at Element14 in Singapore and just a few bucks each, so we could order at 4:30PM and have it delivered the next morning to our office for a very nominal delivery fee.

    After replacing this chip, I was pleased to find that the unit came back alive again. I have to say, I’ve found the hot-air rework skills I learned at Dangerous Prototype’s hacker camp to be incredibly useful; this level of rework is now child’s play for me. I’m not quite sure how we damaged the USB3300 chip in the first place, but one possibility is that someone tried plugging something into the mini-DIN connector on the analyzer that wasn’t meant to be plugged into the device.

    And so, despite this being a closed-source device, it ended up being repairable, although it would have been much more convenient and required a lot less guesswork to fix it had schematics been made available.

    Significantly, the maker of this box was acutely aware of the fact that hardware is difficult to close and attempted to secure their IP by scrubbing the original markings off of the FPGA. An inspection under the microscope shows the surface texture of the top-part of the chip does not match the edges, a clear sign of reprocessing.

    For what it’s worth, this is the sort of thing you develop an eye for when looking for fake chips, as often times they are remarked, but in this case the remarking was done as a security measure. The removal of the original manufacturer’s markings isn’t a huge impediment, though; if I cared enough, there are several ways I could try to guess what the chip was. Given the general age of the box, it’s probably either a Spartan 3 or a Cyclone II of some type. Based on these guesses, I could map out the power pin arrangement and run a cross-check against the datasheets of these parts, and see if there’s a match. Come to think of it, if someone actually does this for Name that Ware based on just these photos, I’ll declare them the winner over the person who only guesses the make and model of the analyzer. Or, I could just probe the SPI ROM connected to the FPGA and observe the bitstream, and probably figure out which architecture, part and density it was from there.

    But wait, there’s more to the story!

    It turns out the project was pretty urgent, and we didn’t want to wait until the next day for the spare parts to arrive. Fortunately, my Tek MDO4000B has the really useful ability to crunch through analog waveforms and apply various PHY-level rules to figure out what’s going on. So, on any given analog waveform, you can tell the scope to try rules for things like I2C, SPI, UART, USB, etc. and if there’s a match it will pull out the packets and give you a symbolic analysis of the waveform. Very handy for reverse engineering! Or, in this case, we hooked up D+ to channel 1 and D- to channel 2, and set the “bus” trace to USB full-speed, and voila — protocol analysis in a pinch.

    Above in a screenshot of what the analysis looks like. The top quarter of the UI is the entire capture buffer. The middle of the window is a 200x zoom of the top waveform, showing the analog representation of the D+ and D- lines as the cyan and yellow traces. And just below the yellow trace, you will see the “B1″ trace which is the scope’s interpretation of the analog data as a USB packet, starting with a SYNC. Using this tool, we’re able to scroll left and right through the entire capture buffer and read out transactions and data. While this isn’t a practical way to capture huge swathes of data, it was more than enough for us to figure out at what point the system was having trouble, and we could move on with our work.

    While the Tek scope’s analysis abilities made fixing our USB analyzer a moot point, I figured I’d at least get a “Name that Ware” post out of it.

    by bunnie at September 28, 2014 07:17 PM

    Winner, Name that Ware August 2014

    The ware for August 2014 was a Dell PowerEdge PE1650 Raid controller. Thanks again to Oren Hazi for contributing the ware! Also, the winner is Bryce C, for being the first to correctly identify make and model. Congrats, email me for your prize!

    by bunnie at September 28, 2014 07:17 PM

    Village Telco

    Introducing Wildernets

    WN-204x264The following is a guest post from Keith Williamson.

    Wildernets is alternative firmware for the MP02 that aims to widen the customer base for the MP02 by making initial configuration much easier and adding new features such as Instant Messaging support. So even if you are comfortable operating a SECN 2.X network (as most are on this forum), you may find some of the Wildernets features of interest.

    Wildernets is based on the latest version of SECN 2.1 but simplifies both the initial and ongoing configuration making it possible for a user with few technical skills to get the network up and running quickly. In addition to SIP and POTS telephony, Wildernets supports Instant Messaging and local Web content service. Wildernets firmware is complementary to SECN 2.X firmware. It targets a slightly different user base than the traditional VillageTelco user but there is certainly a lot of overlap. Deployment assumptions for SECN firmware have generally included an entrepreneur with the technical “chops” to roll out the network and a user base that may have never had access to even basic telephony services. As we added support for softphone client software on smartphones, tablets, and laptops, the SECN network started to become useful for limited emergency services communications and small groups of users who need communications services in environments that are outside the range of traditional PSTN and cellular services. These users are likely to own smartphones, tablets, and laptops that become much less useful in those environments. With a Wildernets network, these devices become very useful again for calling or instant messaging other people on the network and browsing local Web content. Generally, these users already know the basics of downloading, installing, and using Internet applications on their devices but likely don’t know how to setup networks with IP addresses, netmasks, gateways and application services such as telephony and IM servers. Wildernets goal is to remove that impediment.

    For more information check out the Wildernets project page.

     

     

    by Keith Williamson at September 28, 2014 03:55 PM

    September 25, 2014

    Richard Hughes, ColorHug

    AppStream Progress in September

    Last time I blogged about AppStream I announced that over 25% of applications in Fedora 21 were shipping the AppData files we needed. I’m pleased to say in the last two months we’ve gone up to 45% of applications in Fedora 22. This is thanks to a lot of work from Ryan and his friends, writing descriptions, taking screenshots and then including them in the fedora-appstream staging repo.

    So fedora-appstream doesn’t sound very upstream or awesome. This week I’ve sent another 39 emails, and opened another 42 bugs (requiring 17 new bugilla/trac/random-forum accounts to be opened). Every single file in the fedora-appstream staging repo has been sent upstream in one form or another, and I’ve been adding an XML comment to each one for a rough audit log of what happened where.

    Some have already been accepted upstream and we’re waiting for a new tarball release; when that happens we’ll delete the file from fedora-appstream. Some upstreams are really dead, and have no upstream maintainer, so they’ll probably languish in fedora-appstream until for some reason the package FTBFS and gets removed from the distribution. If the package gets removed, the AppData file will also be deleted from fedora-appstream.

    Also, in the process I’ve found lots of applications which are shipping AppData files upstream, but for one reason or another are not being installed in the binary rpm file. If you had to tell me I was talking nonsense in an email this week, I apologize. For my sins I’ve updated over a dozen packages to the latest versions so the AppData file is included, and fixed a quite a few more.

    Fedora 22 is on track to be the first release that mandates AppData files for applications. If upstream doesn’t ship one, we can either add it in the Fedora package, or in fedora-appstream.

    by hughsie at September 25, 2014 01:15 PM

    September 24, 2014

    September 23, 2014

    Free Electrons

    Brevets logiciels : lettre aux députés européens

    La menace des brevets logiciels est de retour, à travers le projet de « Brevet Unitaire » qui est actuellement à l’étude à la Commission Juridique du Parlement Européen. En quelques mots, il s’agit de confier à l’Office Européen des Brevets (OEB) le soin de définir ce qui est brevetable et ce qui ne l’est pas. Or l’OEB est bien connu pour être favorable aux brevets logiciels, et échappe également à tout contrôle démocratique.

    Vous trouverez plus d’informations sur le site brevet-unitaire.eu ainsi que sur le site Stop Software Patents.

    Après les dernières batailles sur les brevets logiciels en 2005, il était temps de reprendre ma plume pour essayer de sensibiliser nos représentants aux dangers que représentent les brevets logiciels. La lettre ci-dessous a été envoyée la semaine dernière à chacun des membres de la commission juridique, en version anglaise ou en version française.

    Il ne s’agit pas d’une étude juridique approfondie sur les brevets logiciels, car je ne suis qu’un ingénieur, ne disposant pas de connaissances juridiques avancées. Il s’agit plutôt du témoignage de mes inquiétudes par rapport à ces brevets, inquiétudes légitimées par les nombreuses dérives observées de par le monde depuis de longues années, et par les multiples pressions que nos législateurs ont subies pour légaliser les brevets logiciels en Europe.

    Il n’est peut-être pas trop tard pour écrire à vos représentants aux parlement Européen, mais en tout cas, il n’est pas trop tard pour signer la pétition que de nombreuses entreprises et de nombreux particuliers ont signée.

    Madame, Monsieur le député européen,

    Je suis le créateur et dirigeant de Free Electrons, une jeune société d’ingénierie en informatique embarquée, qui accompagne des entreprises du monde entier dans la conception de systèmes embarqués, sur un marché à forte croissance.

    C’est la disponibilité d’un grand nombre de briques logicielles Open-Source qui a permis à notre société de connaître une croissance continue depuis sa création en 2004. De très nombreux produits industriels et d’électronique grand public sont conçus à partir de ces briques, développées en commun par une communauté de développeurs dans le monde entier, à laquelle notre entreprise participe.

    Or, cette dynamique aurait pu être atténuée si les brevets logiciels avaient été légaux dans l’UE, comme ils le sont aux États-Unis et au Japon. Par leur nombre et souvent leur trivialité, ces brevets constituent un véritable « champ de mines » pour tout créateur de logiciels et de système embarquant du logiciel. Pour une société aux moyens limités, il est en effet impossible de s’assurer que les idées que l’on met en pratique en programmant, ou les composants logiciels qu’on réutilise, ne «posent pas le pied» sur méthode brevetée par un tiers. Le créateur d’un produit innovant à base de matériel et de logiciel court alors le risque de voir son investissement ruiné par un concurrent plus gros auquel son invention ferait de l’ombre. Ce concurrent, s’il possède un jeu de brevets suffisamment fourni, pourra toujours trouver un brevet logiciel trivial enfreint par le produit concurrent, et faire arrêter la diffusion du produit. Un autre danger vient aussi de sociétés (« Patent trolls ») qui ne créent aucun produit et ne vivent que par la recherche de victimes qui enfreignent des brevets dans leurs produits.

    Il est ainsi inquiétant de constater qu’au moins dans le domaine du logiciel, les brevets sont détournés de leur vocation première de favoriser l’innovation. C’est tout le contraire qui se produit, et il semble que les brevets ne sont aujourd’hui plus qu’un instrument pour des sociétés géantes pour lutter contre leurs concurrents, gros comme petits, et s’opposer à la distribution de produits concurrents. Les premiers brevets accordaient un monopole provisoire en échange de la révélation d’un secret de fabrication. Pour de nombreux brevets logiciels, comme le fameux « double clic » breveté par Microsoft, il n’y a plus de secret de fabrication à révéler, tant leurs effets sont faciles à reproduire. Pourtant, on continue d’accorder un monopole pour ces brevets.

    Notre entreprise est donc inquiète des projets en cours pour installer un brevet unitaire dans l’UE, accompagné d’une cour unifiée des brevets.

    Nous sommes préoccupés du fait que le règlement sur le brevet unitaire, selon l’accord obtenu en décembre 2011 par les négociateurs du Conseil, de la Commission et de la commission des affaires juridiques du Parlement européen, abandonne toute question à propos des limites de la brevetabilité à la jurisprudence de l’Office Européen des Brevets (OEB), sans contrôle démocratique, ni recours devant un tribunal indépendant.

    Pourtant, au mépris du rejet que le Parlement européen a exprimé dans ses votes du 24 septembre 2003 et du 6 juillet 2005, l’OEB a continué à délivrer des brevets logiciels, sous l’appellation trompeuse d’« inventions mises en œuvre par ordinateur ». C’est peut-être parce que l’OEB, échappant à tout contrôle démocratique, a un intérêt financier à délivrer un maximum de brevets, et ainsi alimenter une augmentation des litiges, qui profite aux cabinets d’avocats mais décourage l’innovation, qui pourtant est le principal moteur de notre économie.

    Le règlement sur le brevet unitaire est une opportunité pour les législateurs de l’UE d’harmoniser le droit matériel des brevets dans le cadre institutionnel et juridique de l’UE, et de mettre fin aux pratiques intéressées de l’OEB qui étendent le domaine de la brevetabilité aux logiciels. Si cela échoue, le brevet unitaire sera plus préjudiciable que bénéfique pour les entreprises informatiques européennes.

    Pour ces raisons, nous incitons vivement les législateurs à adopter des amendements qui énoncent clairement que les décisions de l’OEB sont sujettes à un recours devant la Cour de justice de l’Union européenne et réaffirment le rejet des brevets logiciels exprimé par les votes du Parlement Européen.

    N’hésitez pas à me contacter si vous le souhaitez.

    Bien cordialement,

    Michael Opdenacker

    by Michael Opdenacker at September 23, 2014 01:53 PM

    Bonne année 2014 – Accomplissements en 2013

    Cet article est également publié sur notre bulletin d’actualités trimestrielles.

    Toute l’équipe de Free Electrons vous présente ses meilleurs voeux pour l’année 2014, pleine d’optimisme et d’énergie !

    Nous profitons de l’occasion pour vous donner des nouvelles de Free Electrons.

    En 2013, Free Electrons a augmenté sa contribution aux projets Open Source, surtout au niveau du noyau Linux.

    639 patches ont été intégrés au noyau Linux, principalement pour améliorer le support des processeurs ARM de Marvell et d’Allwinner. Pour toutes les versions de Linux publiées en 2013, Free Electrons a fait partie des 30 premières sociétés en termes de contributions (nombre de commits). Nous avons maintenant une expérience forte dans l’intégration du support de processeurs ARM dans le noyau Linux, et nous espérons encore déveloper notre activité dans ce domaine en 2014.

    595 patches ont été intégrés à Buildroot, un système de compilation automatique pour systèmes embarqués, et ceci dans un grand nombre de domaines, faisant de Free Electrons le deuxième plus important contributeur après le mainteneur de Buildroot. Ce travail permet à Free Electrons de tenir à jour son expertise en compilation croisée et en outils de compilation de systèmes de fichiers embarqués.

    26 patches intégrés au chargeur de démarrage Barebox :

    22 patches au « layer » pour Freescale dans Yocto, principalement pour prendre en charge les cartes embarquées de Crystalfontz. Nous en avons profité pour développer un nouveau type d’image et d’importantes améliorations ont été apportées à la recette de compilation pour Barebox.

    Certaines de ces contributions, ainsi que bien d’autres activités, ont été réalisées dans le cadre de projets de développement et de conseil en 2013, en particulier :

    • Développement de code pour le noyau Linux, ajoutant à la version officielle du noyau Linux le support de processeurs ARM ou de cartes embarquées de nos clients, en particulier sur les processeurs de Marvell et de Freescale.
    • Développement noyau, de pilotes de périphériques et intégration dans un système de compilation pour l’embarqué, pour un appareil médical basé sur un processeur SAMA5 d’Atmel.
    • Développement de pilotes de périphériques pour noyau Linux pour des émetteurs-récepteurs à radio-fréquences, sur une plateforme domotique à base d’Atmel SAMA5.
    • Projets de réduction du temps de démarrage.
    • Projets de conseil et d’audit autour de Buildroot.

    Nous avons également amélioré et mis à jour de façon significative nos formations :

    • Notre formation développement de pilotes de périphériques noyau Linux a été mise à jour pour utiliser la plateforme BeagleBone Black, pour couvrir l’utilisation du Device Tree sur plateforme ARM, et pour utiliser un périphérique I2C amusant pour illustrer le développement d’un pilote de périphériques dans nos travaux pratiques.
    • Notre formation Android : développement système a été mise à jour vers Android 4.x, et pour utiliser la BeagleBone Black comme plateforme de développement dans les travaux pratiques.
    • Notre formation Linux embarqué a été mise à jour pour utiliser des versions plus récentes du noyau Linux, en particulier pour couvrir l’utilisation du Device Tree sur plateformes ARM.

    Nos supports de formation restent librement disponibles sous licence Creative Commons, y-compris leur code source, disponible via un dépôt Git public.

    Free Electrons continue de croire à l’importance pour ses ingénieurs de participer aux conférences techniques, pour les tenir au courant des derniers développements autour de Linux et pour renforcer les liens avec les développeurs de la communauté, qui permettent à nos projets d’avancer plus vite. Pour cette raison, nous avons participé à un grand nombre de conférences en 2013 :

    • FOSDEM 2013, à Bruxelles, Belgique. Notre directeur technique et ingénieur Thomas Petazzoni a donné une présentation sur le développement noyau sur ARM.
    • Buildroot Developers Meeting, Bruxelles, Belgique. Notre ingénieur Thomas Petazzoni a organisé et à participé à cet événement, parrainé par Google, autour du développement de Buildroot.
    • Embedded Linux Conference 2013 et Android Builders Summit 2013, à San Francisco, États-Unis. Notre ingénieur Grégory Clement a donné une présentation sur l’infrastructure de gestion des horloges (« clock framework ») dans le noyau Linux. Notre ingénieur Thomas Petazzoni a donné une présentation sur le développement noyau sur ARM. Voir aussi nos vidéos.
    • Linaro Connect Europe 2013, Dublin, Irlande. Notre ingénieur Thomas Petazzoni a participé à de nombreuses discussions autour du support des processeurs ARM dans le noyau Linux.
    • Linux Plumbers 2013, Nouvelle Orléans, États-Unis. Notre ingénieur Maxime Ripard a assisté à la conférence, et a participé à des discussions autour du développement noyau et Android.
    • Kernel Recipes, Paris, France. Notre Directeur Michael Opdenacker et notre Directeur Technique Thomas Petazzoni ont participé à cette conférence sur le noyau Linux, et Thomas a donné deux présentations: une sur le développement noyau sur ARM et une sur Buildroot.
    • ARM kernel mini-summit 2013, Édimbourg, Royaume-Uni. Nos ingénieurs Grégory Clement, Thomas Petazzoni et Maxime Ripard ont participé au mini-sommet sur le noyau ARM, réservé aux développeurs principaux sur ARM. Ce sommet est un l’endroit où se discutent et se définissent les directions à prendre pour le support des processeurs ARM dans le noyau Linux.
    • Embedded Linux Conference Europe, Édimbourg, Royaume-Uni. Grégory Clement a donné une présentation sur l’infrastructure de gestion des horloges dans le noyau Linux et Thomas Petazzoni a donné une présentation sur le Device Tree.
    • Buildroot Developers Meeting, Édimbourg, Royaume-Uni. Notre ingénieur Thomas Petazzoni a organisé et participé à cet événement de 2 jours, parrainé par Imagination Technologies, sur le développement de Buildroot.

    Un développement très important pour Free Electrons en 2013 est l’embauche d’un nouvel ingénieur dans notre équipe : Alexandre Belloni nous a rejoint en mars 2013. Alexandre a une expérience très significative en Linux embarqué et en développement noyau. Plus d’informations sur son profil.

    Abordons maintenant nos projets pour 2014 :

    • Recruter plusieurs nouveaux ingénieurs. Un d’entre eux a déjà signé et nous rejoindra en avril, en apportant une solide expérience en développement noyau, y-compris en contribution au noyau officiel.
    • Notre implication dans le support des processeurs ARM dans le noyau Linux se développera de manière substantielle.
    • Deux nouvelles formations seront offertes : une formation sur la « Réduction du temps de démarrage » et une formation sur « OpenEmbedded et Yocto ».
    • Pour la première fois, nous organiserons des sessions inter-entreprises (ouvertes à inscription individuelle) en dehors de France.
      • Notre prochaine session en anglais sur « Android : développement système » se tiendra du 14 au 17 avril à Southampton, Royaume-Uni
      • Nous préparons également des sessions sur Linux embarqué et sur le noyau Linux aux États Unis, qui devraient être annoncées dans les semaines qui viennnent.
      • Nous projetons également d’organiser des sessions sur les mêmes sujets en Allemagne, avec des formateurs germanophones.
      • Au passage, nos formations en français sur Android continueront à être données à Toulouse, mais il y aura aussi une session du 1er au 4 avril à Lyon.

      Vous pouvez consulter the la liste complète de nos sessions inter-entreprises.

    Tout comme en 2013, nous participerons à plusieurs des plus importantes conférences techniques: Linux Conf Australia (Janvier 2014), FOSDEM (Février 2014), Embedded Linux Conference (Avril 2014) et Embedded Linux Conference Europe (Octobre 2014).

    Vous pouvez suivre les actualités de Free Electrons en lisant notre blog et en suivant nos nouvelles brèves sur Twitter. Nous avons maintenant aussi une page Google+.

    Une fois de plus, Bonne Année 2014 !

    Toute l’équipe de Free Electrons.

    by Michael Opdenacker at September 23, 2014 01:49 PM

    Actualités trimestrielles Free Electrons: mai 2014

    Cet article est également publié sur notre bulletin d’actualités trimestrielles.

    Free Electrons a le plaisir de partager avec vous des nouvelles des activités de formation et de contribution de la société.

  • Prise en charge d’une nouvelle plateforme ARM : l’exemple des processeurs Allwinner – Maxime Ripard
  • by Michael Opdenacker at September 23, 2014 01:49 PM

    Actualités trimestrielles Free Electrons: septembre 2014

    Cet article est également publié sur notre bulletin d’actualités trimestrielles.

    Free Electrons a le plaisir de partager avec vous des nouvelles des activités de formation et de contribution de la société.

    Contributions au noyau Linux

    Depuis notre dernier bulletin d’informations, nos ingénieurs ont continué à faire d’importantes contributions au noyau Linux, en particulier dans le domaine du support des processeurs ARM et des plateformes utilisant ceux-ci.

    • 218 patches de Free Electrons ont été intégrés à Linux 3.15, ce qui place Free Electrons au 12ème rang des sociétés qui ont contribué à cette version, en nombre de patches. Voir notre billet de blog.
    • 388 patches ont été acceptés dans Linux 3.16, ce qui fait de Free Electrons la 7ème société contributrice à cette version. Voir notre billet de blog.
    • Pour la version 3.17 à venir, nous avons déjà intégré 146 patches, et nous avons beaucoup de travail en cours pour les versions suivantes.

    Voici nos principales contributions :

    • L’ajout d’un pilote ubiblk, qui permet d’utiliser des systèmes de fichiers traditionnels au dessus de devices UBI, et donc sur du stockage flash de type NAND. Il n’y a que le mode en lecture seule qui est pris en charge, mais cela permet déjà d’utiliser SquashFS, un système de fichiers très performant, de manière sécurisée sur de la flash de type NAND.
    • Un autre ajout est celui des nouveaux processeurs Marvell Armada 375 et Armada 38x. En seulement deux versions (sorties des versions 3.15 et 3.16), nous avons pratiquement poussé le support complet de ces nouveaux processeurs. Le pilote réseau pour l’Armada 375 est une pièce manquante, qui apparaîtra dans la version 3.17.
    • Notre travail de maintenance sur les processeurs AT91 et SAMA5 d’Atmel s’est poursuivi, avec davantage de conversions au Device Tree, au Common Clock Framework, et à d’autres mécanismes modernes du noyau. Nous avons également développé le pilote graphique DRM/KMS pour le SoC SAMA5D3, qui a déjà été publié et qui devrait être intégré prochainement si tout va bien.
    • Notre travail pour prendre en charge le processeur Marvell Berlin a commencé à être intégré à Linux 3.16. Ce processeur est utilisé dans divers téléviseurs, lecteurs multimédia ou dans des petits appareils comme la Google Chromecast. Un support de base a été intégré, comprenant les Device Trees, les pilotes d’horloges, le pilote pinmux, ainsi que la prise en charge des GPIO et de SDHCI. Le support d’AHCI devrait arriver en 3.17, et le support USB et réseau est attendu pour 3.18.
    • Le travail sur la prise en charge des SoCs d’Allwinner s’est poursuivi, en particulier sur le processeur A31 : prise en charge de SPI et I2C, pilotes pour le bus bus et pour le contrôleur PRCM, et le support de l’USB.

    Nous disposons maintenant d’une expérience assez complète en écriture de pilotes pour le noyau et intégration de code dans les sources officielles du noyau. N’hésitez pas à nous contacter si vous avez besoin d’aide pour développer des pilotes pour le noyau Linux, ou pour prendre en charge une nouvelle carte ou un nouveau processeur.

    Contributions à Buildroot

    Notre implication dans le projet Buildroot, un des plus populaires outils de compilation de systèmes de fichiers pour l’embarqué, s’est poursuivie. Nous avons intégré 159 patches à la version 2014.05 du projet (sur un total de 1293 patches), et 129 patches à la version 2014.08 (sur un total de 1353 patches). De surcroît, notre ingénieur Thomas Petazzoni joue souvent le rôle de mainteneur par intérim, quand Peter Korsgaard, le mainteneur, n’est pas disponible. Voici les fonctionnalités principales que nous avons ajoutées : améliorations majeures de la prise en charge de Python 3, ajout de chargeurs de démarrage EFI, support de la bibliothèque C Musl.

    Projets Linux embarqué

    Bien-sûr, nous avons également conduit des projets de développement Linux embarqué et de réduction du temps de démarrage pour divers fabricants de systèmes embarqués, avec un impact moins visible sur les projets de la communauté. Cependant, nous essaierons de partager l’expérience générique que nous avons pu acquérir via de futurs billets de blog.

    Nouvelle formation : Yocto Project et OpenEmbedded

    Un grand nombre de projets Linux embarqué utilisent des systèmes de compilation automatique qui intègrent les divers composants d’un système dans une image de systèms de fichiers prête à l’emploi. Parmi les solutions existantes, Yocto Project et OpenEmbedded sont très en vogue.

    Nous avons ainsi développé une nouvelle formation de 3 jours, Yocto Project et OpenEmbedded, pour aider les ingénieurs et les sociétés qui utilisent, ou sont intéressés par utiliser ces solutions pour leur projets Linux embarqué. En commençant par la compréhension des principes de base de Yocto, la formation rentre dans les détails de l’écriture de recettes de paquetages, de la prise en charge d’une carte par Yocto, de la création d’images sur mesure, etc.

    Le programme détaillé de la formation est disponible. Vous pouvez commander une session sur site, ou bien participer à notre première session inter-entreprises organisée à Toulouse du 18 au 20 novembre.

    Mise à jour de la formation Linux embarqué

    L’écosystème de Linux embarqué évolue très rapidement, et donc nous mettons constamment à jour nos formations vis à vis des derniers développements. Dans le cadre de cet effort, nous avons récemment procédé à une mise à jour majeure de notre formation Linux embarqué : le matériel utilisé dans les travaux pratiques est passé à la populaire et intéressante carte Atmel Xplained SAMA5D3, et de nombreux travaux pratiques ont été améliorés pour un apprentissage plus facile. Voir notre billet de blog pour plus de détails.

    Liste de discussion pour les participants à nos formations

    Nous avons mis en place un nouveau service pour les participants à nos sessions de formation : une liste discussion qui leur est dédiée, et sur laquelle ils peuvent poser toutes questions supplémentaires après la formation, partager leur expérience, et se mettre en contact avec d’autres participants et avec les ingénieurs de Free Electrons. Bien-sûr, tous les ingénieurs de Free Electrons sont sur la liste et participent aux discussions. Encore un service utile offert par nos sessions de formation !

    Voir plus de détails.

    Conférences : ELC, ELCE, Kernel Recipes

    L’équipe d’ingénierie de Free Electrons participera aux conférences Embedded Linux Conference Europe et Linux Plumbers, le mois prochain à Düsseldorf en Allemagne. Plusieurs ingénieurs de Free Electrons donneront également des présentations à ELCE :

    De surcroît, Thomas participera aussi au Buildroot Developers Day, qui se tiendra à Düsseldorf juste avant l’Embedded Linux Conference Europe.

    Voir aussi notre billet de blog sur ELCE pour plus de détails.

    Maxime Ripard et Michael Opdenacker participeront également à la conférence Kernel Recipes 2014 à Paris, du 25 au 26 septembre. Maxime donnera sa présentation noyau Allwinner à la conférence. Voir notre billet de blog pour plus de détails.

    Enfin, nous avons récemment publié les vidéos d’un certain nombre de présentations à l’Embedded Linux Conference, qui s’est tenue en avril à San Jose. Cela représente une bonne quantité d’informations intéressantes sur Linux embarqué ! Voyez vous-même sur notre billet de blog.

    Prochaines sessions de formation

    Nous proposons un certain nombre de sessions de formation en inter-entreprises, dans lesquelles nous avons encore des places disponibles :

    Sessions et dates

    by Michael Opdenacker at September 23, 2014 08:42 AM

    Altus Metrum

    keithp&#x27;s rocket blog: easymega-118k

    Neil Anderson Flies EasyMega to 118k' At BALLS 23

    Altus Metrum would like to congratulate Neil Anderson and Steve Cutonilli on the success the two stage rocket, “A Money Pit”, which flew on Saturday the 20th of September on an N5800 booster followed by an N1560 sustainer.

    “A Money Pit” used two Altus Metrum EasyMega flight computers in the sustainer, each one configured to light the sustainer motor and deploy the drogue and main parachutes.

    Safely Staged After a 7 Second Coast

    After the booster burned out, the rocket coasted for 7 seconds to 250m/s, at which point EasyMega was programmed to light the sustainer. As a back-up, a timer was set to light the sustainer 8 seconds after the booster burn-out. In both cases, the sustainer ignition would have been inhibited if the rocket had tilted more than 20° from vertical. During the coast, the rocket flew from 736m to 3151m, with speed going from 422m/s down to 250m/s.

    This long coast, made safe by EasyMega's quaternion-based tilt sensor, allowed this flight to reach a spectacular altitude.

    Apogee Determined by Accelerometer

    Above 100k', the MS5607 barometric sensor is out of range. However, as you can see from the graph, the barometric sensor continued to return useful data. EasyMega doesn't expect that to work, and automatically switched to accelerometer-only apogee determination mode.

    Because off-vertical flight will under-estimate the time to apogee when using only an accelerometer, the EasyMega boards were programmed to wait for 10 seconds after apogee before deploying the drogue parachute. That turned out to be just about right; the graph shows the barometric data leveling off right as the apogee charges fired.

    Fast Descent in Thin Air

    Even with the drogue safely fired at apogee, the descent rate rose to over 200m/s in the rarefied air of the upper atmosphere. With increasing air density, the airframe slowed to 30m/s when the main parachute charge fired at 2000m. The larger main chute slowed the descent further to about 16m/s for landing.

    September 23, 2014 04:33 AM

    September 19, 2014

    Video Circuits

    Video Workshop

    Here are pics of the analogue video workshop packs each attendee will be getting tomorrow! http://encounters-festival.org.uk/news/events/analog-video-workshop/

    by Chris (noreply@blogger.com) at September 19, 2014 05:14 PM

    September 13, 2014

    Altus Metrum

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

    AltOS 1.5 — EasyMega support, features and bug fixes

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

    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 EasyMega board and a host of new features and bug fixes

    AltOS Firmware — EasyMega added, new features and fixes

    Our new flight computer, EasyMega, is a TeleMega without any radios:

    • 9 DoF IMU (3 axis accelerometer, 3 axis gyroscope, 3 axis compass).

    • Orientation tracking using the gyroscopes (and quaternions, which are lots of fun!)

    • Four fully-programmable pyro channels, in addition to the usual apogee and main channels.

    AltOS Changes

    We've made a few improvements in the firmware:

    • The APRS secondary station identifier (SSID) is now configurable by the user. By default, it is set to the last digit of the serial number.

    • Continuity of the four programmable pyro channels on EasyMega and TeleMega is now indicated via the beeper. Four tones are sent out after the continuity indication for the apogee and main channels with high tones indicating continuity and low tones indicating an open circuit.

    • Configurable telemetry data rates. You can now select among 38400 (the previous value, and still the default), 9600 or 2400 bps. To take advantage of this, you'll need to reflash your TeleDongle or TeleBT.

    AltOS Bug Fixes

    We also fixed a few bugs in the firmware:

    • TeleGPS had separate flight logs, one for each time the unit was turned on. Turning the unit on to test stuff and turning it back off would consume one of the flight log 'slots' on the board; once all of the slots were full, no further logging would take place. Now, TeleGPS appends new data to an existing single log.

    • Increase the maximum computed altitude from 32767m to 2147483647m. Back when TeleMetrum v1.0 was designed, we never dreamed we'd be flying to 100k' or more. Now that's surprisingly common, and so we've increased the size of the altitude data values to fit modern rocketry needs.

    • Continuously evaluate pyro firing condition during delay period. The previous firmware would evaluate the pyro firing requirements, and once met, would delay by the indicated amount and then fire the channel. If the conditions had changed state, the channel would still fire. Now, the conditions are continuously evaluated during the delay period and if they change state, the event is suppressed.

    • Allow negative values in the pyro configuration. Now you can select a negative speed to indicate a descent rate or a negative acceleration value to indicate acceleration towards the ground.

    AltosUI and TeleGPS — EasyMega support, OS integration and more

    The AltosUI and TeleGPS applications have a few changes for this release:

    • EasyMega support. That was a simple matter of adapting the existing TeleMega support.

    • Added icons for our file types, and hooked up the file manager so that AltosUI, TeleGPS and/or MicroPeak are used to view any of our data files.

    • Configuration support for APRS SSIDs, and telemetry data rates.

    September 13, 2014 06:47 PM

    September 10, 2014

    Elphel

    More lenses tested: Evetar N123B05425W vs. Sunex DSL945D

    We just tested two samples of Evetar N123B05425W lens that is very similar to Sunex DSL945D described in the previous post.

    Lens Specifications

    Sunex DSL945D Evetar N123B05425W
    Focal length 5.5mm 5.4mm
    F# 1/2.5 1/2.5
    IR cutoff filter yes yes
    Lens mount M12 M12
    image format 1/2.3 1/2.3
    Recommended sensor resolution 10Mpix 10MPix


    Lens comparison

    Both lenses are specified to work with 10 megapixel sensors, so it is possible to compare “apples to apples”. This performance comparison is based only on our testing procedure and does not involve any additional data from the lens manufacturers, the lens samples were randomly selected from the purchased devices. Different applications require different features (or combination of features) of the lens, and both lenses have their advantages with respect to the other.

    Sunex lens has very low longitudinal chromatic aberration (~5μm) as indicated on “Astigmatism” (bottom left) graphs, it is well corrected so both red and blue curves are on the same side of the green one. Evetar lens have very small difference between red and green, but blue is more than 15 μm off. My guess is that the factory tried to make the lens that can work in “day/night” applications and optimized design for visible and infrared spectrum simultaneously. Sacrificing infrared (it anyway has no value in high resolution visible light applications) at the design stage could improve performance of this already very good product.

    Petzval field curvature of the DSL945D is slightly better than that of the N123B05425W, astigmatism (difference between the sagittal and the tangential focal shift for the same color) is almost the same with maximum of 18 μm at ~2 mm from the image center.

    Center resolution (mtf50% is shown) of the DSL945D is higher for each color, but only in the center. It drops for peripheral areas much quicker than the resolution of the N123B05425W does. Evetar lens has only sagittal (radial) resolution for blue component dropping below 100 lp/mm according to our measurements, and that gives this lens higher full-field weighted resolution values (top left plot on each figure).

    Lens testing data

    The graphs below and the testing procedure are described in the previous post. Solid lines correspond to the tangential and dashed – to the sagittal components for the radial aberration model, point marks account for the measured parameter variations in the different parts of the lenses at the same distance from the center.

    Sunex DSL945D

    Fig.1 Sunex SLR945D sample #1020 test results

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

    Evetar N123B05425W

    Fig.2 Evetar  N123B05425W sample #9071 test results

    Fig.2 Evetar N123B05425W sample #9071 test results. Spreadsheet link.

    Fig.3 Evetar  N123B05425W sample #9072 test results

    Fig.3 Evetar N123B05425W sample #9072 test results. Spreadsheet link.

     

    by andrey at September 10, 2014 08:25 PM

    September 09, 2014

    Free Electrons

    Séminaire gratuit sur Android le 29 janvier à Gardanne

    Android robotLe programme Captronic organise un séminaire gratuit sur Android et son utilisation dans les systèmes embarqués. Celui-ci se tiendra le 29 janvier à Gardanne, près de Marseille, et sera présenté par mon collègue Maxime Ripard, qui est le créateur de notre formation sur le développement système avec Android.

    Matinée

    • Présentation générale d’Android
    • Opportunités d’utiliser Android dans des systèmes embarqués qui ne sont ni des téléphones ni des tablettes
    • Détails sur l’architecture d’Android et sa personnalisation
    • Code source et compilation
    • Modifications apportées par Android au noyau Linux
    • Chargeurs de démarrage pour Android
    • Prise en charge d’un nouveau matériel
    • L’organisation du système de fichiers d’Android
    • Les couches natives d’Android et l’appel d’un programme C depuis Android pour l’accès à un matériel spécifique
    • Introduction au développement d’applications
    • Personnalisation du système
    • Utilisation d’adb (Android Debug Bridge) pour la mise au point et le contrôle à distance du système.
    • Ressources et bonnes pratiques

    Après-midi

    • Démonstrations de plusieurs aspects du développement de systèmes avec Android
      • Récupération des sources et compilation
      • Démonstration de l’émulateur d’Android
      • Démarrage d’Android sur une carte électronique à base de processeur ARM OMAP 3530, en utilisant une console série.
      • Prise en compte de boutons spécifiques. Exemple de la touche « Back ».
      • Utilisation d’adb : installation, accès au logs du système, accès à une ligne de commande sur l’équipement, échange de fichiers avec le PC.
      • Personnalisation du système : changer le nom du produit, le fond d’écran par défaut, rajouter une nouvelle propriété.
      • Pour l’accès à un matériel spécifique (un périphérique USB par exemple), développement d’une bibliothèque native et accès à cette fonctionnalité depuis le framework Android via une classe et une bibliothèque JNI spécifiques.
      • Présentation d’une application permettant de contrôler un périphérique USB.
    • Questions et réponses

    L’inscription est gratuite mais une inscription préalable est requise. Voir la page de Captronic sur ce séminaire.

    Par ailleurs, les transparents de ce séminaire sont disponibles dans leur intégralité. Cela vous permettra de vous assurer que le séminaire correspondra à vos attentes.

    by Michael Opdenacker at September 09, 2014 12:01 PM

    Michele's GNSS blog

    At ION GNSS+ 2014

    To whom it may happen to be in Tampa these days: I will also be around.



    Feel free to come and chat!

    by noreply@blogger.com (Michele Bavaro) at September 09, 2014 11:04 AM

    September 07, 2014

    Video Circuits

    Tomislav Mikulic

    "Tomislav Mikulic is a Croatian computer Graphics pioneer who exhibited at the Tendencies 5 in Zagreb(former Yugoslavia) in 1973 at the age of 20. He had composed the First Yugoslav Computer Animation Film which had it’s premiere on 13th May 1976 in Zagreb.324"


















    http://tomislavmikulic.com
    http://dada.compart-bremen.de/item/agent/585


    by Chris (noreply@blogger.com) at September 07, 2014 09:01 AM

    September 06, 2014

    ZeptoBARS

    74HC4094 - 8-bit shift register : weekend die-shot

    74HC4094 is an 8-bit serial-in/parallel-out shift register.


    September 06, 2014 09:43 PM

    September 02, 2014

    Zedstar

    NibbleKiosk: controlling chromium through sound

    **updated for verison 0.0.2**

    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. A key variable is getting the right signal magnitude to trigger the system. You can use the -m flag to experiement with this. On a Raspberry Pi I have set this as low as -m 2, e.g.

    nibblekiosk -d test.db -m 2

    I have had good performance from the microphone on an old USB webcam or if you want something small for the Pi, Konobo makes a very small USB microphone.

    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 September 02, 2014 08:15 PM

    Bunnie Studios

    Name that Ware, August 2014

    The Ware for August 2014 is below.

    Sorry this month’s ware is a little bit late, I’ve been offline for the past couple of weeks. Thanks to Oren Hazi for contributing this ware!

    by bunnie at September 02, 2014 05:12 PM

    Winner, Name that Ware July 2014

    The Ware for July 2014 is a GSM signal booster, bought over the counter from a white-label dealer in China. There were many thoughtful, detailed and correct responses, making it very hard to choose a winner. Lacking a better algorithm than first-closest response, wrm is the winner. Congrats, email me for your prize!

    by bunnie at September 02, 2014 05:10 PM

    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

    Altus Metrum

    bdale&#x27;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 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 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 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

    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

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

    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

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

    Extension points are first released in OCaml 4.02. You will need to switch to 4.02 or a newer compiler, preferably using opam:

    1
    2
    
    opam switch 4.02.1