A project log for Open Sensor Array

Open Sensor Array provides a host platform with unified interface and API for all kinds of sensors and measuring device.

AtherosAtheros 03/13/2015 at 22:404 Comments

The inspiration

I had the idea for some time now to make a portable sensor device, something that I could deploy whenever I need some measurements done or some alarm setup. A few days ago when I was trying to figure out a project that fits The Hackaday Prize 2015, the idea came back, but I didn't think it is good enough. First of all, the number of possible sensor is huge, fitting it all together would be very unpractical. Then some of those sensors consume considerable amount of power, so putting that all together would require either carrying a backpack filled with batteries or external power supply. Those reasons made me drop the idea initially.

Later that day when I was playing Lego Duplo with my daughter, I say her joining a few 2x4 bricks one on top of the other. I started to wonder if it would be possible to replace those bricks with sensors and stack them together as needed just as with Lego. I though why not? Arduino is doing it, others too, so maybe this is the way to go?

The problem

The advantage of this design is you have a lot of components common (battery, MCU, bluetooth or wifi, display, ...) and replace sensor modules as needed. There are however problems.

Communication bus

Since there is supposed to be different number of different sensor modules, you cannot just a single PCB, write some code and be done with it. This project needs some communication bus and some protocol. This is because the main MCU needs to be able to discover what sensor modules are plugged in, what kind of services (or readings) do they provide and a way to access them.

On the lower level I was thinking about SPI, I2C, RS232 and RS485.

RS232 cannot be used as it is point-to-point system. Having multiple RS232 signals passing through all boards would require a lot off wires and would limit the number of modules that can be used (the highest number of UARTS in a MCU I ever saw was 8). I rejected software serial communication too, as I will need processor time for other work.

RS485 fixes all of the previous issues but adds a few others. RS485 was designed for industrial purposes, it works very well at long distances with a range exceeding 1km. This felt like an overkill. The second issue was the fact that none of the microcontrollers I was considering have a RS485 transmitter, so I would have to have an additional external component which I want to avoid.

SPI was a better choice, as it is widely available. The only issue is similar to RS232, I would need a lot of extra wires to select the correct module to transmit to (or receive from), and I would need to restrict the maximum number of modules. I'll use SPI to communicate with the display module instead.

The last option I was considering was I2C. Just like RS485, it is a multi-point protocol, however it was designed to work on much shorter ranges and should me more efficient for this project. The huge bonus is it is available in many microcontrollers. In my oppinion this is the best solution solution for my problem, at least for now.

Physical connection

The second major problem is the connection between bricks, both mechanical and electric. In Lego you just plug different components and it just work. You are however limited to the bricks the manufacture designed and is currently selling, unless you want to spend a lot of time designing the component, 3d print it, test it and probably restart from the beginning if it doesn't work correctly. This is time consuming and not always the best way. I believe electronics work the same so I'm trying to use as many existing solutions and components for problems that don't really deserve a custom approach.

I need to be able to connect multiple PCB boards together, and I don't want to spend too much time or money on it. I immediately rejected the use of cable connections because manually creating short cables is very cumbersome, except maybe for IDC cables. Those on the other hand are too difficult to handle in very constrained spaces.

I though of course about goldpin headers, unfortunately the usual stacking of PCBs like in Arduino doesn't leave much space between boards, and I already know I'll have sensor exceeding 2.5cm in height. My though was to use angle pins and sockets. The idea is not very bad, the physical connection is definitely worse, it is less rigid and the components needed are rather difficult to find, at least where I live. Since I don't want to waste more time on this problem, for the prototype stage this will have to do.

What next?

As I have already some bits figured out, I will focus on acquiring the components I know I will need. I will also try to figure out how to connect sensor modules and maybe make some tests. I'll try to have something ready by the end of next week.


davedarko wrote 03/14/2015 at 00:19 point

I would look for a connection of the modules that could support IIC/TWI and SPI, since most sensor chips talk either one of those. Something like a 2x6 port, where 1x6 is GND, VCC, SDA, SCL and 2 or 4 pins are (binary encoded) chip select for the other 1x6 SPI interface, depending if you want an extra GND/VCC on the SPI side or not. Since the concept sounds a bit familiar, it could help to check out the #Open Source Science Tricorder

Do you have chosen a MCU yet? The arduino pro micro is like the teensy able to work as a keyboard - combined with some jquery magic you could use a browser app as a logging interface. Sounds a bit exotic, but works over USB OTG.

Anyway, good luck and happy hacking!

  Are you sure? yes | no

Atheros wrote 03/14/2015 at 09:01 point

With SPI I would have to have lots of chip select signals which I don't really want. The issue is I will want anywhere between 1 and 16 sensor modules attached (or more), with SPI this would require 16 chip select signals.

I saw the tricorder project, it's seems very nice and well designed. Peter Jansen sure set the bar very high with his user interface and all the features packed in that small handheld device. In any case the goals of those two projects aren't exactly the same and I hope the differences will become more obvious as this project develops.

As for the MCU, I'm thinking either about a spark core and teensy for now. They should be enough for a nice UI and bluetooth communication. I am also looking into small linux boards, if I find one that eats reasonable amount of power, I will consider it.

  Are you sure? yes | no

davedarko wrote 03/14/2015 at 10:16 point

I thought about 4pins == 16 values in binary  - that would mean something on every module to "decode" the information, like a bcd decoder and a small switch. But I don't know what size you want to achieve, so adding 16 decoders might let explode your board sizes. On the other hand you could say you support 4 SPI interfaces and how much IIC devices IIC does support.  

I hope you don't feel offended, my intention was not to say that you should do it like him and I see and value your approach with the smartphone as an interface! His module connectors are a mix out of GPIOs and SPI/IIC and I thought that was quite clever, since you may get modules that need something like a wake up pin or other stuff. While writing I've noticed something, you only need one pin per module connector for a chip select, as long as you don't want to stack them. I'd say use a small mcu and let the mobile do the work. 

Anyway, I've always wanted a "smart" shell/case for my cell phone and this reminds me of it, that's why I'm posting all my thoughts here :) Hope you don't mind, but this feels like something I want to make as a project for the prize myself. 

  Are you sure? yes | no

Atheros wrote 03/14/2015 at 15:34 point

No worries, I'm not offended :)

I don't plan to have room for a demultiplexer and it still doesn't solve the problem of assigining IDs to individual modules.

As for the modules themselves, the idea is that each one has it's own processor, so it can handle whatever sensors you can imagine and put the values in my protocol. I was thinking for now to put atmegas on those, as it's the fastest way to start for me. The drawback is I'll be using the only I2C channel for communication, so I2C sensors won't be available for me. If it becomes a problem, I'll try to find a chip with multiple I2C channels.

The plan to solve I2C addressing is using a dipswitch and later the automatic detection (I already have some ideas how to implement it).

  Are you sure? yes | no