Components

During last week, we've been thinking about the device size and ways to split it into smaller expandable chunks. We finally decided on the following:

• Controller board
• Signal distribution board
• Power supply board
• Sensor modules
• Case

The extra components make this device a bit less portable than I originally planned, it may however become a bit more useful in different areas.

Controller board

This board will have the main CPU on board, the display and some input (rotary encoder?). It will also host a SD card port and some communication ports.

As mentioned before, I'm currently considering plugging in a Teensy ARM board as the brain.

Signal distribution board

This board will be mostly passive (depending on communication protocol we choose), and will contain female goldpin slots (2x10?) for modules. It will also contain ports for the controller board and power supply board.

Power supply board

The power supply board is a very important component of Open Sensor Array. It's job will be to create a stable 3.3V and 5V power supply.

Initially I was thinking about making this part of the signal distribution board, but then I though there are so many battery options out there or recharging sources that making this board replaceable is rather important.

Sensor modules

We decided sensor modules will be of the size of a standard credit card. Why? Because it is hard to come up with a number, if we don't have any modules designed yet.

The case

The case is supposed to be "portable", unfortunately not as in smartphone or the Open Source Science Tricoder. We plan to make more than one case. At least two, one for 2 or 3 sensor modules, which will make it small enough and one with room for 8 or more modules, for situations where small size and portability is not as important. This of course requires us to design more than one distribution board.

Communication bus

Here comes very difficult choices. There aren't a lot of multi-point communication methods that can be used in a hobby project. What we considered were the following solutions:

• CAN bus
• I2C
• RS-232 ring
• Serial Peripheral Interface Bus
  
• RS-485

CAN bus

Controller Area Network bus could have been a suitable choice. The only issue was no controller I wanted to use had CAN integrated, those that have it are a lot more expensive. This idea was dropped very fast.

I2C

I was considering I2C too. There were however some issues: unique addressing of nodes, hotplug support, not so simple voltage level shitfters and a faulty module can hang the entire bus.

BWA proposed to solve the issue of addressing by assigning a hardwired ID number on the signal distribution board.

Unfortunately the other issues weren't really solved. There are ICs that solve some of those issues, they are however very expensive.

RS-232 ring

This is a simple idea, you take the TX of the controller and connect it to the RX of the first module, then you take it's TX line and connect it to the RX of the next module, and so on until you return to the RX of the main controller.

This might have worked if the design wasn't modular. If there was some bypass to connect RX/TX pins of an unconnected device, you still have a problem with interrupted transmission when you connect a new module.

The above issues could of course be solved, but the work required would be important, as well as solving bugs in such system could also be a nightmare.

Serial Peripheral Interface Bus

The idea of SPI is really simple. You basically have a shift register on each device and you transmit bits with a given clock signal and slave select pin. I don't think you can go a lot simpler than that. I had the idea that I could use an I2C GPIO extender to select individual slave select pins and go with this solution.

All was great and perfectly simple until I have read this: (here)

"Disadvantages (...) SPI does not support hot plugging (dynamically adding nodes)."

I really hope this is only about the issue you can't just get a new Slave Select line out of nowhere (no SS line sharing).

I'll investigate this more later.

RS-485

This is an other usefull solution. RS-485 is a multipoint communication system or electrical characteristics. In any case, RS-485 transceivers are quite cheap and by themselves handle different voltage levels on controller side. They can be driven by simple UARTS and provide a simple way to interface hardware at ranges up to 1KM.

Unfortunately, it seems it comes at a price. Extra IC, higher power consumption and a bit of extra complication.

Which communication bus to choose?

Right now the fight is between SPI and RS-485. I don't know which we will chose, but hopefully there will be an answer soon.