Project Logs

Collapse

• Components and Communication bus

  Atheros • 03/26/2015 at 16:46 • 1 comment

  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...

  Read more »

• Planning...

  Atheros • 03/13/2015 at 22:40 • 4 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...

  Read more »

View all 2 project logs