More blogs in Arm Community blogs
Tags
Actions
Related blog posts
Related forum threads

Missed the Sensor Fusion Hangout? Catch up on ARMFlix!

Eric Gowland

If you missed the live Sensor Fusion and Contextual Awareness Hangout, you can watch the playback on the ARMFlix channel on Youtube here:

You can find bios of all the participants on the intro blog here.

I asked Will Tu of ARM, who facilitated proceedings, for his 'Top 3' highlights:

1) Innovation in sensors is happening on multiple vectors

  • At the same time that people in multiple industries are experimenting with new use cases, device makers are bringing new types of sensor to market.
  • Sensors are being retro-fitted into agriculture, industry and other settings to pull little data into closed loop, big data decision making - leading to more effective and efficient businesses.
  • The cross section of multiple types of sensor data is where the value is - John Logan of Microchip referenced fitness trackers, which with the addition of heart rate data to movement and activity tracking are now much more insightful health devices.

2) But some of the challenges are the same...

  • Most sensor applications fall into the 'always on' category - this requires low power devices, particularly for battery powered wearables or remotely deployed sensing platforms.
  • At the same time, there is a greater demand for processing power to interpret multiple streams of raw data and provide useful information to applications.
  • Power versus Performance - but at a different scale that varies between every application!

3) Ecosystem is key

  • The companies innovating with sensors are diverse. Some, like mobile developers, have strong software expertise. Others, like small embedded device builders, may not.
  • Partners like Hillcrest Labs Labs and Bosch Sensortec help match solutions to the level of expertise and experience a product development team has.
  • Turn key solutions, be they hardware or software, will enable players without pre-existing expertise to innovate and bring new ideas to market.

The second point really jumped out at me as playing to what many would call the core strengths of ARM and our partners - including that balancing of power versus performance in ever more varied and demanding applications.

Enjoy the show!

Anonymous
Parents

  • Having a digital camera with built-in GPS is a real good example on a device which benefits from having two or more sensors.

    Taking a snapshot no longer puts you in doubt where it was taken; you just look up the GPS coordinates and get an exact location.

    It's great to combine sensors to provide combined information; but a thing I've been thinking of quite a lot is the interface connecting the sensor(s) to the microcontroller.

    We have SPI, which is used by many sensors, and it's great; really great; it's quick, it's simple and it uses very few pins.

    We also have I2C, which is slower, but use fewer pins.

    And we have CANBUS, which has a brilliant way of auto-assigning IDs; it's also great for fairly long distances between nodes.

    We have one-wire sensors, which also auto-enumerates the connected devices.

    There's also RS485 (which is old, but still not obsolete - it's used actively in the marine industry).

    Finally, there's the cool SWD interface/protocol, which allows for bi-directional data transfer on a single wire.

    What if we had a "sensor-bus", an interface, which had the best qualities of the above mentioned bus/interface types.

    Sensors are usually input-devices, but there are times where you want to configure sensors (change settings), so I believe it should be possible to transmit data to the sensors as well.

    Would it be possible to combine the best features of the above interfaces (plus those interfaces I forgot), so that we no longer need 10 CS pins in order to select the sensor we want to talk to, and can still transfer the data quickly on long distances using only very few wires ?

    I'm thinking a little like ... seeing it from the master's side: rising edge on the clock = read, falling = write.

    This might not be the optimal way of transmitting data quickly, but it allows you to have just 3 wires: GND, CLK and DIO.

    Perhaps differential signals such as a DIO+, DIO-, CLK+ and CLK-, in order to extend the range, but only as an extension to the 'basic' interface.

    I haven't spent much time thinking about the how and why, but I believe it would be great to be able to connect a 16 pin microcontroller to a whole bunch of devices, without having to I/O-extend via I2C to get 14 extra Chip-Select pins...

Comment

  • Having a digital camera with built-in GPS is a real good example on a device which benefits from having two or more sensors.

    Taking a snapshot no longer puts you in doubt where it was taken; you just look up the GPS coordinates and get an exact location.

    It's great to combine sensors to provide combined information; but a thing I've been thinking of quite a lot is the interface connecting the sensor(s) to the microcontroller.

    We have SPI, which is used by many sensors, and it's great; really great; it's quick, it's simple and it uses very few pins.

    We also have I2C, which is slower, but use fewer pins.

    And we have CANBUS, which has a brilliant way of auto-assigning IDs; it's also great for fairly long distances between nodes.

    We have one-wire sensors, which also auto-enumerates the connected devices.

    There's also RS485 (which is old, but still not obsolete - it's used actively in the marine industry).

    Finally, there's the cool SWD interface/protocol, which allows for bi-directional data transfer on a single wire.

    What if we had a "sensor-bus", an interface, which had the best qualities of the above mentioned bus/interface types.

    Sensors are usually input-devices, but there are times where you want to configure sensors (change settings), so I believe it should be possible to transmit data to the sensors as well.

    Would it be possible to combine the best features of the above interfaces (plus those interfaces I forgot), so that we no longer need 10 CS pins in order to select the sensor we want to talk to, and can still transfer the data quickly on long distances using only very few wires ?

    I'm thinking a little like ... seeing it from the master's side: rising edge on the clock = read, falling = write.

    This might not be the optimal way of transmitting data quickly, but it allows you to have just 3 wires: GND, CLK and DIO.

    Perhaps differential signals such as a DIO+, DIO-, CLK+ and CLK-, in order to extend the range, but only as an extension to the 'basic' interface.

    I haven't spent much time thinking about the how and why, but I believe it would be great to be able to connect a 16 pin microcontroller to a whole bunch of devices, without having to I/O-extend via I2C to get 14 extra Chip-Select pins...

Children
No Data
Embedded and Microcontrollers blog