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

  • pcbscape wrote:

      Is your design is restricted by BOM costs, PCB real estate etc ?

    The sensor-bus is more a "generally speaking" suggestion, but normally, I would of course try reducing the used PCB space, including the number of external components.

    Sometimes you want to place many sensors outside the PCB; such as several meters from the CPU (example: temperature sensors on a boiler).

    Sometimes you need the PCB to fit in a tiny space and have several high-speed sensors on the PCB (perhaps on both sides).

    If you could have a single 'sensor-bus', it might reduce the code size, because all code written for the sensors share the same interface, and thus do not need to set up different interface types and speeds each.

    I very much fancy SPI, due to its simplicity (a shift-register is basically all you need in order to create an SPI device) and the flexible speed.

    However, if SPI was combined with the auto-enumeration CANBUS has (eg. a verification of the Data-Out pin, so each device could stop transitting as soon as it discovers that someone else is talking), then I would find it vastly improved; this would also reduce the need for a CS pin.

Comment

  • pcbscape wrote:

      Is your design is restricted by BOM costs, PCB real estate etc ?

    The sensor-bus is more a "generally speaking" suggestion, but normally, I would of course try reducing the used PCB space, including the number of external components.

    Sometimes you want to place many sensors outside the PCB; such as several meters from the CPU (example: temperature sensors on a boiler).

    Sometimes you need the PCB to fit in a tiny space and have several high-speed sensors on the PCB (perhaps on both sides).

    If you could have a single 'sensor-bus', it might reduce the code size, because all code written for the sensors share the same interface, and thus do not need to set up different interface types and speeds each.

    I very much fancy SPI, due to its simplicity (a shift-register is basically all you need in order to create an SPI device) and the flexible speed.

    However, if SPI was combined with the auto-enumeration CANBUS has (eg. a verification of the Data-Out pin, so each device could stop transitting as soon as it discovers that someone else is talking), then I would find it vastly improved; this would also reduce the need for a CS pin.

Children
No Data
Embedded and Microcontrollers blog