Folknology Labs

iBOM Part 4 – Expanding the market

folknology — Tue, 06 Sep 2011 21:20:15 +0000

Production on the backend isn’t the only thing holding back opensource hardware, getting from innovation and good ideas into any sort of distributed production requires initial investment. In some cases it can be very small, but unlike opensource software there are physical requirements of pcbs, parts and tools that have very real costs! the iBom part of the equation could be connected in here also by the likes of an Octopart, either by aquiring someone like KickStarter or by rolling their own distributed investor community. This would have the effect of ‘quickening’ the front end in order to supply the backend and would facilitatte the emergence of a ‘Market’ which is the next key part of the move to distributed production. It doesn’t take an Einstein to take this further and envision market places bolted onto the innnovation front ends for successful projects, thus closing the circle and providing positive feedback whilst encourage fresh new agile growth.

*Update I added an iBom repo to get started on the idea/format etc..

iBOM part 3 – Reinventing Production

folknology — Tue, 06 Sep 2011 20:31:00 +0000

So in this new world of iBoms and meta-iBoms what changes? Well pretty much everything, electronics construction gets dragged kicking and screaming into the 21st Century. Open Hardware production becomes much more simplified and distributed. But why should Octopart do such a thing? Well they could pull a Google on the Electronics supply chain for a start, that’s got to be worth something? We get great footprints and metadata, our opensource tools (Kicad/Geda) would improve significantly I would expect it would be in the interests of say an Octopart to invest into those tools and help devolop them. I could even imagine Octopart buying Github and integrating project management into the whole iBOM, pretty soon it would mean that the buyers would start stearing the component manufacturers/vendors indicating whats needed to be made to make our lives easier rather than the dictorial arrangement we currently have with them. It will also change how things are manufactured in general, with the combination of this and 3D printing technologies (RepRap et al) things could be produced nearer their destination rather than being shipped half the way around the world as they currently are (highly in efficient). That sort of change could make huge differences to the future economies of not just electronics but manufacturing itself.

iBOM part 2

folknology — Tue, 06 Sep 2011 20:01:27 +0000

Ok so say we have iBOMs, this in itself could be extended further to make it even more powerful. Imagine that all of the items in an iBOM could be iBOMs themselves from individual components through to component modules and entire projects. Then we would be able to assemble modular constructions of arbitarly complex parts we would even be able to create Meta Projects with meta iBOMs. So how do we get there, how do we get components and modules as iBOMS? Well the modules could be fairly simple as they are in control of those creating the OpenSource Hardware projects (and opensource sofware iBOMs), the tricky piece is the individual components. Well I have several ideas here; if Octopart were a third party iBOM operator they could start creating iBoms for all available components. Sure this sounds like a lot of work and they probably couldn’t do it all themselves, they would need help from the community. Here is one way they could incentivise the community. They could create a standard component description file (a component iBOM) that also included additional useful information. This could be used to not only identify the component but also produce/derive the various footprints for the component using a standard opensource tool/script. By doing this the iBom file for the component could be used by various CAD packages to bring in valuable footprint databases much needed in the community. Octopart could create a database of popular component iBoms for the open source community (ones commoly used like Atmega328s) to kick start the open iBOM DB process. That would encourage their use and also encourage others in the community to start adding their own iBoms back to the open iBOM database (basically component iBom files on say github). If the iBOMs were done correctly to also capture contextual information like the component usage (used in production) and quality (peer review/rating) perhaps a contextual metabase over the top could add qualative selection criteria magnify the iBOMs worth, this would provide confidence in the iBOMs use for a designer and proliferate there use.

Part 3 coming shortly..

Thoughts?

Intelligent Bom

folknology — Tue, 06 Sep 2011 19:21:06 +0000

iBOM Part 1

I found my self in conversations recently around the progression of OpenSource Hardware development and moving it’s production forward. I have long been interested in distributed open production and have talked about this for some time. In a recent conversation with one of my colleagues (Ken) about how his project Nanode could be moved forward and made more accessable to a larger audience. We were wondering in particularly about solving the production problem, in the nanode’s case it was kit based. We came to the conclusion that it would be cool if we could produce a BOM as part of the project that would be more enabling to potential participants in the project. I suggested to Ken the idea of an hyperlinked BOM, in it’s simplest form being a link to a preloaded basket at different distributor suitable for each geographic location. After thinking about this some more I came up with the concept of the Active or even the Intelligent BOM (aBOM/iBOM). with an iBom you basically have a hyperlink (hBOM)to a web based service which takes a standard BOM, creates multiple baskets and chooses components from a range of suppliers and best choices. It could also offer basket optimisation like cheapest, or fewest suppliers etc.. dependent on the BOM contents and or quantities/preferences you might provide. For it to work you would provide a standard file format BOM text file in your project repository (on say github) you could then create a REST based link to the thrird party iBom provider e.g.

http://ibom.com?source=github.com/myproject/mybom

Whe the user clicks on this link they are taken to the third party and presented with various competitive baskets to buy the projects components (or vitamins as RepRapers call them!). You could even produce PCB with the URL (even QRcode/barcode) on them so folks can populate them more easily, or produce the PCBs themselves and then populate using the iBom.

So who could provide such a third party

I will expand this further in Part 2

Would love your thoughts as usual..

Amino Clarification

folknology — Mon, 07 Mar 2011 15:05:14 +0000

The Amino Project has evolved over the last couple of years from a need for higher performance and modularity than I could find in the opensource hardware world. Turns out I was far from alone in my desires for such a solution. Although initially I worked on possible ARM based solutions when others expressed opinions that strategy changed and we adopted Xmos as a core part off the architecture. In between those periods I was hoping to use FPGA and MCU combinations but a conversation with Omerk back in November 2009 moved the conversation onto Xmos. But we would like to indicate that this isn’t the final chapter for Amino on the architecture front and in the background we are still exploring both FPGA, MCU and Asic approaches to solving the issues we face in modularity and performance at this level.

This brings me to the point of this post then which is the clarification of what Amino really is. It is all to easy to let Amino’s scope drift away from it’s initial goals and become either to specialist or all to encompassing. So we would like to make a clarification for Amino going forward. In addition I would also like to clarify Folknology Lab’s role in Amino.

Amino is primarily concerned with the definition of a hardware interface. This will allow modular hardware components to be mixed and matched in order to build hardware prototypes, applications or solutions. So Amino’s primary documentation and focus should be concerned with the interface specification which is something we are working on and hope to get something concrete out shortly. In order to reach a point where this makes sense Folknology Labs has been building experimental open implementations of the standard. In this regard Amino Beta is purely an experimental Implementation on the Amino interface specifications, it does not represent a shipping or commercial product. Indeed anyone can and should make Amino compliant products, be they blades or boards that house blades. we also need to state that Amino does not decide the exact form factor of a blade or a blade holder, rather it concentrates on the pinout function and spacing. Thus one can for example have horizontal blades, indeed Folknology Labs has several design of this type for housing single or double horizontal blade configurations. However if more than 2 blades are required to be attached to a single board then a vertical arrangement is clearly needed, hence the initial design of Amino Beta using vertical blades. This has been asked about quite a lot by the way..

Obviosuly Amino interfacing is primarily about the hardware interface specification, in order to make these blades work together with different Amino boards however, there needs to be some standardisation around software, as well as the electrical characteristics. Initially this will be based around Xmos toolchains as that is the initial architecture used for the implementations but it is clearly not confined to that, later we hope we can expand this across other architectures whilst maintaining the benefits of a common interface.

One of the things we need to do after testing Amino Beta is make an initial release of documentation and implementation examples in a common area for everyone to access and perhaps participate in if they feel passionately about the idea. My initial idea is to use Github to house the project and use opensource tools where possible to create implementation examples. Amino Beta by the way was created in Eagle and we will release those files as part of this process, however we are trying to move everything over to Kicad (including our libraries) which will better support version control process provided by git, this is due to Kicad’s use of open format and text files unlike Eagle’s more restrictive binaries. We Cannot guarantee That Amino Beta will be ported as it is just a first example (porting is a lot of work), but future implementation examples will most certainly be created in Kicad.

We also hope to finalise the electrical and physical Amino interface standard by the end of March so that we can focus on implementations and software ASAP, clearly if there are any changes you wish to put forward or include, now is the time to do so.

Where does Folknology Labs sit within this? Well Folknology Labs is likely to create its own implementations of Amino and see it as an important part of its hardware and software strategy moving forward, but that doesn’t represent a reference implementation, rather it would represent Folknology Labs implementation, in other words Folknology Labs != Amino or vice versa..

So please let us know your thoughts on moving Amino forward, should we use github or some other method? how would you like to see Amino move forward, what sort of license should we use etc..

Amino Beta Introduction and Tour

folknology — Thu, 24 Feb 2011 17:16:05 +0000

I figured I would introduce the hardware interfaces using a simple board tour of Amino Beta before diving into the specific concepts of the hardware modularity.

Above shows the Amino Beta PCB layout and board views which will help in this whistle stop tour.

Components

Starting in the centre we have a Xmos XS1-L1 64LQFP which is nerve centre of the board. Other components on the board include oscilator, voltage and reset management along with flash memory storage for operating the board and its modules. The power regulation (south west quadrant) is switch mode based, providing 3.3V and 1V delivering about 6.5 Watts powering itself and its peripherals and modules, this choice also saves design complexity and cost for add-ons.

Connectors

In order to program and debug this board (essential at this stage!) we have the Xmos SYS connector at the top left facing north. This will enable the use of Xmos’s Xtag/Xtag2 USB debugging tools to be attached to the running board. At the top right facing north we have a 6 pin right angled header for communications extensions which is capable of operating in conjunction with the Xmos Sys connector. To the east we have a channel extender (right angled box header) facing east which can be used to optionally interconnect boards if required. The 10 pin female header (north west quadrant) is to enable experimentation with on-board features prior to finalisation.
The most interesting connectors are the remaining female headers providing the standard modular slots which I will focus on next, these are highlighted better in the illustration below as A,B and C.

These standard interface slots formed around female 0.1″ headers, allow fixed dimension plug-in boards to be connected at right angle to the Amino Beta board. One can visualise the main Amino board as a back plane to these plugin “Blades”. This concept of Blades is different from the motherboard, daughter-board or shield like concepts and is more akin to something like rack mounted boards with a back-plane. This design is key to Amino Beta’s architecture and the main interfacing concept moving forward. It enables multiple boards to be plugged into Amino providing much greater modularity. Blades come in 3 main types 4bit, 8bit and cooperative. A full slot like B and C can accommodate all types of Blade but the smaller A slot can only furnish a 4bit Blade. Although Amino Beta provides only 3 slots for blades, there is no real limit to the number of blades that could be accommodated for more sophisticated designs later on. However There are some design rules and specifications about what a slot must provide in order to accommodate a given type of blade. Below illustrates an empty blade to give you an idea of layout.

The male right angled 0.1″ headers on the west of the blade slot into the Amino Beta board female headers. An example connector (dual row right angled 0.1″) to the east of the blade would represent the blade’s input or output to the real world and or other systems, right angled connectors can be used in many different forms limited only by width and height in order to be fair to one’s blade neighbour. In this way all Input and outputs to the Amino system are exposed on the same dimension parallel to the Amino Beta board (back plane) this is also forms part of the standardisation and modularisation of the Amino concept. In the next post I will go into more detail about blades usage and specifications.

Amino Beta Status and Build

folknology — Thu, 24 Feb 2011 14:31:15 +0000

received the Amino Beta prototype boards this week along with the paste stencil, I will be building and testing these during March. In order to build these I need to verify my new build process and am currently waiting on some small test sample boards to verify my new process. Given new build pitfalls I figured it would be better to test my new process with smaller low cost boards rather than diving in at the deep end with Amino Beta Builds.

Below you can see a couple of pics of the Amino Beta stencil and 4 prototype printed circuit boards. The boards are double sided FR4, 35µmCu, 1,6mm with solder mask, I have used PCB Pool to produce the prototypes as they do a reasonable deal including steel stencil which suits my new build. Amino Beta requires their finer Layout specifications >= 0.125mm (5mil)and >= 0.2mm (8mil) due to its tight layout and decoupling requirements. I could perhaps have achieved lower specs by populating both top and bottom with surface mount components, particularly decoupling, but that in turn raises build costs and is not compatible with my current build process. I should also add that modular add on hardware is not constrained in this manner as the interfaces are based around standard 0.1″ pitch headers.

Amino Beta Prototype PCBs

Amino Beta Stencil

I will keep you posted on the build process and will probably have some more news on the boards later in March. In the meantime I will step through the Amino Beta design and more importantly its modular hardware interfaces.

Amino Beta

folknology — Thu, 24 Feb 2011 13:58:33 +0000

Amino Beta has been designed in order to complete the Amino project hardware design phase by providing a suitable platform to test and finalise the project design goals, it should therefore not be considered complete and is thus subject to change. We expect however these changes to be minor during this final ‘Beta’ Stage of the project development. Nevertheless for project participants it is best to keep up to date with the project community to stay abreast of any changes, in particular anyone developing hardware compatible with the project should pay particular attention to start up configuration as this is the area most likely to change over the next few months.

Initially to some it may appear that the Amino Beta board is somewhat sparse compared to its various predecessor designs around Amino Alpha, this is in fact a purposeful decision in order to increase flexibility, modularity and access. Amino Beta’s simplicity also allows more diverse communication choices to be explored before committing to designs including on-board communications, this was done in order to expedite the finalisation of Amino hardware design phase. Had we waited for communications finalisation it would have delayed the completion of the more urgent modular hardware design phase. In other words we wanted to get something concrete out there to work with, particularly for those interested in designing hardware modules! This is in part also due to folks badgering me about moving forward, thank you for the encouragement, sometimes I need a kick in order to stop procrastinating

So over the next few weeks I want to concentrate on the modular hardware design and explain how Amino Beta is designed and how one can build compatible modular hardware. The next few posts will concentrate on explaining Amino Beta hardware interfaces and updating its current status. through this period I am hoping that feedback from yourselves will help finalise the project and enables us all to start producing working hardware.

Amino update

folknology — Sat, 20 Nov 2010 17:01:07 +0000

Well its been 6 long months since my last post here, I must apologise for that unprecedented delay. I have been tied up with an existing commercial software project which has been extended in its scope. But I haven’t been idle with the Amino work. The last 6 months of work around it have been focused on the missing fifth tenet of Amino requirements, lets remind ourselves of the original four:

project, so lets remind ourselves of that projects initial aims:

Modularisation – A modular topology enables common components to be snapped together using composition, allowing focus on just the custom features of a given project or task, it also reduces complexity and leads to faster project turnaround.

Standardisation – In order to have modulisation and composition as well as reuse, standardisation is required via opensoource implementations made available for testing, production, modification and experimentation.

Digitisation – Opensource software is perfectly digital it’s reproduction is as simple as copying bits, hardware isn’t so simple, but the more of it that can be digitally expressed and rendered the easier its reproduction and the more accessible it becomes to a larger audience.

Reuse – Being able to reuse as much hardware and software as possible reduces consumption and is more environmentally friendly. Common modules or components can be assembled at reduced cost minimising overlap, they can be reused time and time again for experimentation and prototyping. Hacking culture often seeks to reuse, mashup and redefine items for use elsewhere, design should embrace this modern form of cultural reuse.

The fifth is Communication and it is an essential ingredient for Amino moving forward, without it Amino becomes another island technology. Initially I took the default recommended path, going with USB as primary and adding other options like TCP/IP as secondary mechanisms. This choice makes things simple as USB can carry both power and data and is ubiquotous enough via the common all garden PCs we are all to familiar with.

Little did I realise what I was getting into however, USB is a bit of a minefield with different connectors, versions and complex driver requirements on both ends of the cabling. Add to that Amino’s high requirements and I was soon having issues with the design and workload. The straw that broke the camels back however was the can of worms implementation considered standard on the Xmos family of development boards, along with its debugging tools like Xtag2. The deeper you dig the more screwed up it becomes. Finally after 6 months of fighting it I gave it up as a lost cause, opensopurce USB for Amino is a no go.. I am sad that I spent so long worki ng out what an evolutionary cul-de-sac it was.

Moving on however I decided to accelerate my preferred long term plans for Amino’s communication architecture based around TCP/IP. In the last couple of months I have redesigned the entire project around TCP/IP communication and it will come with a network stack included. I hope in the longer term to port all tools over to TCP/IP with help from the community, I will talk more about this in a later Post.

The Amino hardware reference design (Formerly Amino Alpha) is nearing design completion and will offer even greater support for all 5 tenets than Alpha could have even hoped too. Its getting quite exciting and I think you will like the new design. I am dedicating the next few of months to getting the refernce platform out, starting with a couple of prototypes followed by a small early adopter build for those that have been and hopefully will continue to get involved early on. If you interested in getting your hands dirty and helping to get the platformed developed at an early stage let me know and I will include you in alpha geek first build.

I will provide some more of the design details in the next month or so as soon as the prototype layout is finished. I just wanted to provide a brief update where we are with Amino, as usual if you have any questions around this please feel free to comment or contact me..

regards

Al

Amino Alpha

folknology — Fri, 30 Apr 2010 09:11:00 +0000

I have been very busy in the Folknology labs working through tens of different designs and boards as part of the Amino project. I am now at a point where I have a design for the first candidate Amino board – Amino Alpha. Below is an image of the boards layout, with highlighted I/O connectors, let me briefly show you around.

Communications

For communications we have full speed USB (480Mb/sec) and 10/100Bt Ethernet, the connectors for these can be seen to the north of the board. There is also a serial comms connector “C” to the left of the Ethernet RJ45, this houses dedicated UART and I2C pins. Also notice there is an optional MicroSD card slot underneath the mini USB connector facing northwards.

Analogue

Interface “A” on the westside of the board provides a minimum 4 channel multiplexed analogue interface (we may add more channels here), based around a 10bit successive approximation ADC which is buffered over SPI, offering minimum conversion time of approximately 2.5 microseconds.

Digital

Alpha provides 2 high bandwidth nibble ports “B” and “D” to the south of the board, with channels capable of shifting up to 50MB/sec. Each port contains 4 1 bit bidirectional I/O pins and a single 4 bit bidirectional (nibble) channel. Together they provide effectively 16 bits of bidirectional I/O. In addition we have 3 further I/O pins which are currently uncommitted (we are currently reserving their use for more complex peripherals and a more modular expansion scheme), these sit between ports B and D along with some power and control pins.

External Debugging

To the west of the board lies interface J, providing a set of JTAG pins which can be used with Xtag or Xtag2 boards connected with only minor modifications/adaptors. This interface is used to debug the management and communication layer of the Amino stack and is not used for either regular participant space development or low level hardware layer development. Both of these development layers are debugged onboard without the need of an extra Jtag/Xtag adaptor. But obviously for ourselves and other alpha geeks this additional debug option is crucial. I will talk more about the layers in the Amino stack in a separate post later.

Components

The main meat inside is obviously the brain and the nervous system made up of 2 XMOS XS1 L-64 chips. One of which (East) provides the nervous system, handles the low level I/O and Ethernet systems space, East is responsible for running low level layer 1 code which will conform to a modular service interface which unlike operating system drivers gets out of your way. The other (West) the brain, manages the entire Amino system including comms (TCP/IP,USB,Serial), memory and participant sketch/application space. The other chips handle lower level PHY, comms and ADC hardware.

I will be sharing the schematics over the next few days to provide more detail and feedback, in the meantime let me know your thoughts. I am still routing the boards so there may be some subtle changes before the first prototypes are made, but generally it should be very similar.

P.S. We are also considering a more robust industrial version which could add Canbus + CANopen, POE and grade 5 components for more harsh environments, if that’s of interest let me know.