Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Gumband Hardware

The Gumband system is designed to natively control and monitor low level embedded systems within an exhibit. The hardware in this context is typically a microcontroller-based platform that is used to control an Exhibit’s electromechanical components. Gumband exposes an MQTT based API for hardware to directly interact with either the Gumband Cloud or a specific Exhibit via the Gumband SDK.

Supported Hardware

Native Gumband Hardware

Gumband Hardware, is a custom embedded system design for new Exhibit development on Gumband, it is a wired ethernet platform built around an Infineon PSoC chip with dual core ARM processor. It has the Gumband stack built-in to seamlessly monitor and interact with physical hardware such as buttons, sensors, LEDs, and motors. This platform also allow for remote firmware updates across a fleet of hardware.

  • ARM M0+ core handles the entire Gumband communication stack

  • ARM M4 core is entirely available for user firmware

  • Program using the Arduino IDE with the Gumband board library

  • Program natively through Infineon PSoC Creator (advanced)

  • Two 2x13 connectors (100mil pitch)

  • 40 multipurpose GPIO pins

  • Existing API supports I2C, UART, SPI, Ethernet, PWM, ADC

  • Additional protocols (RS485, CAN, LIN, ModBus, etc.) supported by MCU

Gumband Module

The native Gumband Hardware is also available as a module in a smaller SMT form factor without losing any functionality from the larger board. Requiring only an external Ethernet connector it is designed to be incorporated directly into a custom circuit board designed for your end application. At 35mm square it is small enough to be incorporated directly into almost any custom system.

Gumband Breakouts

The Gumband Hardware is designed to be the brains of a larger system, as such it is anticipated that these modules be attached to a carrier board specific to the end application. Designs exist for basic breakout capabilities such as screw terminals, high current relays, and stepper drivers. For highly-specific functionality, an accessory board can be designed, similar to a Pi HAT or Arduino Shield. The Gumband team has the capacity to design such custom breakouts if needed. Mechanical drawings for mounting purposes and ECAD footprints and specification are available.

Embedded Systems with Networking

Microcontrollers with networking capabilities can enable Gumband functionality using our Gumband library that supports an expanding list of common wired and wireless networked embedded systems. Alternatively a custom implementation of the Gumband stack can be implemented by adhering to the defined MQTT protocol and the outlined Gumband topic hierarchy.

Embedded Systems without Networking

Microcontrollers without networking capabilities can enable Gumband functionality by using the native Gumband Hardware as a passthrough to the platform. To communicate with the Gumband system a microcontroller must support communication over SPI or UART and use the supported Gumband API library.

Packaged Hardware

The Gumband team are working on releasing packaged plug and play systems for specific applications (relay control, simple IO etc.), please reach out for further enquiry (→ HELP LINK).

Hardware Peripherals and Properties

In Gumband nomenclature a Peripheral is a named assembly of physical hardware components within an Exhibit. Each Hardware device will typically have one or more Peripherals.

Peripherals serve only as an organizational structure within which to group Properties. A Property is either an input or output of that hardware device. Inputs include buttons, switches, encoders, etc. and outputs include LED color, LED brightness, relay state, motor speed, etc. Each physical component within the Peripheral can have one or more Properties.

Peripheral and Property groupings are defined and implemented by the firmware developer when programming any Gumband hardware.

Peripheral Example

If we imagine a scenario where a motor is used to turn a physical wheel mechanism as part of an Exhibit. The Hardware device could have a Peripheral (“Wheel”) that has two Properties (“Speed” and “Direction”). If necessary, that same Hardware device could control other Properties and Peripherals or they could be attached to the Exhibit using additional Hardware.

Monitoring Gumband Hardware

The Gumband Hardware natively reports its current status upon establishment of a connection to both the Gumband cloud and the Gumband exhibit. The initial connection handshake includes a manifest of all peripherals and properties of the current exhibit instance in addition to a packet containing status information about the hardware, including:

  • Device ID

  • Assigned IP

  • MAC Address

  • Gumband Firmware Version

  • User Firmware Version

  • Exhibit IP

  • Exhibit Connection Status

  • System Voltage

  • Last Reboot Reason

Regular heartbeats are sent every 16 seconds supporting more realtime information regarding the current state of the device:

  • Exhibit IP

  • Exhibit Connection Status

  • Voltage

  • Temperature

  • Uptime

  • No labels