User:Aprins/MambaNet

MambaNet Introduction
Equipment developed with the last available technologies become more and more complex to control. Often there is a lot of (virtual) functionality available. You can access this functionality by a screen, keyboard and mouse. But some applications required dedicated and direct control via hardware and/or (embedded)software from remote locations. This is for example a requirement in the 'live' audio industry (Radio/TV broadcasting studios), where a lot of audio-storage and processing takes place in 'computers' (e.g. virtual mixing/play out).

The functionality which is required, is not delivered by a single company. Often you can select a range of products/brands. In practice this brings a question: 'How will all my equipment work together?'

The radio studio example shows that in the past, and also in current implementations, the pieces of audio equipment are connected through remotes (also called GPIO). In fact, this are TTL or Relais inputs and outputs where you have a hardwired connection between products.

With the raising amount of functionality its complex make profit of all the functionality in your devices, using the same 'control interface'. This is the point where MambaNet could be very interesting.

Definitions
An unique identified software process or PCB/hardware. For modularity its possible to have multiple nodes in a physical device. The node can send and receive data with this objects.
 * Node

This represents a element that can be set or triggered by an user. To trigger an object (think of pushing a butten), you can implement a sensor part. To set an object (think of setting a LED/Display), you can implement a actuator part.
 * Object

A sensor waits for an user action or timeout and sent its information to the network if desired.
 * Sensor

A actuator receives information from the network, which may set a LED or fader etc.
 * Actuator

An engine is a special node type. This type of node is allowed to process sensor changes and to sent actuator changes. Infact the engine is the part that gives manufacture specific functionality to a device. For example the radio studio mixing console has one engine, the virtual mixing console. But is has multiple nodes that control the engine, this can be the control surface or any software application.
 * Engine

Specification
Most availble control protocols (e.g. [SNMP]) are based on the client-server principle. For MambaNet it is important that its works multi-master, so a controller at a 'button surface' can inmediately contact its functional counterpart.
 * Multi master

It is required to protocol can run from 8 bits micro controllers till advanced machines, which means the the physcal connections that have to run MambaNet can be different as well. Currently MambaNet is implemented over RS232, CAN, Ethernet and TCP/IP.
 * Medium and Transport Layer independent

To simplify to way of thinking, the protocol has an object oriented design. That means you are allowed to design your own node with objects and share in a MambaNet network. Even there is a registration method for the objects, which is required to implement in a node. With this information the protocol will be future proof and its easy use MambaNet enabled products from other manufacturers (Without knowing the device).
 * Object oriented design

The protocol is developed by D&R Electronica B.V. they maintain a list of manufacture IDs (The protocol allows 65534 manufactures to get their own ID). For local development one ID is left free, this means end-users can also make their own MambaNet complaint software/hardware. (In the radio studio example this can be very interesting for local and regional broadcast facilities). With the reservation of a Manufacture ID a range of 4294836225 Unique numbers is available for this single manufacturer.
 * Open for all manufactures to use


 * On a node you can have up to 64k custom objects. The limit is determined by the footprint in your controller/application.


 * Althought to protocol is designed for tiny controllers its still possible to have relative large messages (for an embedded system). You can send up to 98 bytes per single MambaNet message.

Each node contains a list of all available objects. This list gives a description and data type/ranges an object works with. All this information makes it possible for engine's to 'discover' a device and make use of its objects. Practical this means the engines are future proof and can use equipement from manufacturers they even do not know about.
 * Auto learning of nodes.

Data formats
There are some primitive data types that can be used in MambaNet: A part of a object is not implemented (e.g. a LED only has an actuator part)
 * No data

Can be a position or speed.
 * Unsigned integer

Think of a controller if a offset variable (e.g. an encoder)
 * Signed integer

For example to select an samplerate you can have 2 states: 44.1kHz and 48kHz
 * State

Is an array of bytes which can be used to set a text string on a display.
 * Octet string

Makes it possible to set values in the float format (e.g. temperature or dB level).
 * Float

Usefull you want to set several bits (e.g. status bits or LED bar).
 * Bit string

The datatype that contains all information to learn objects of a node.
 * Object information

This indicates an error occured, the text string gives information in 'ASCII'.
 * Error

Compatibility
MambaNet will run over various physical and transport layers. Currently we have focused on CAN and Ethernet.

On the CAN network MambaNet can no coexist with other protocols, this because the addressing scheme makes advanced use of the CAN identifiers.
 * CAN

MambaNet over Ethernet will adapt the level 2 Ethernet standard (communication by MAC addresses). This means MambaNet can run over standard ethernet networks (e.g. your data network). It will be possible to run MambaNet in parallel with any other Ethernet protocol that runs on Ethernet level 2. For example its no problem to run MambaNet in combination with the audio streaming protocol CobraNet. Also a higher level protocol like LiveWire (based on RTSP) can be a good combination. Ofcourse you always have to care there is enough bandwidth on your network to do all tasks you require!
 * Ethernet