Introduction

The CAN-E-BUS (pronounced /ˈkænəbɪs/) — Controller Area Network Extended BUS was developed by a joint effort of Misty Robotics’ Pipeline Hardware and Eco Software Engineering departments as a token ring message broadcast system that provides high uptimes while addressing the high latency and low throughput of the traditional CAN bus.

Overview

Unlike traditional networks such as USB or Ethernet, CAN-E-BUS doesn’t send large, boring blocks of data point-to-point from node A to node B under the supervision of a central bus master. In a CAN-E-BUS network, many short messages (called DRAWs — Dispensing Ready Adaptive Wrappers) are instead sent via individual data dispensers. DRAW messages are broadcast to the entire network, providing smooth data consistency in every node.

What inspired Misty Robotics to roll our own bus protocol implementation? We wanted to avoid the issue many other bus protocols have, where a slow pipe can munch data. With CAN-E-BUS, messages are small, simple, and typically quite profound. CAN-E-BUS also implements additional mechanisms, called SHOVE and KICK, to prevent token bogarting. To further improve data transmission quality, we built Percolator, a high-performing noise filter.

Potential usage of CAN-E-BUS is not limited to Scientific, Medical, Robotics, AI (Alternative Intelligence), and DL (Dream Learning) applications. Additionally, CAN-E-BUS has been successfully tested in recreational environments for AR (Augmented Reality) data transfer.

Misty Robotics Global HQ

Issues

We observed marked slowing of data transmission once the network went beyond N (number of users) +1 joints.

Additionally, overheating of the CAN-E-BUS network can cause thermal degradation of data nodes and reductions in perceived user experience.

Conclusion

After extensive internal testing, we found that there were no engineering issues with CAN-E-BUS that anyone could remember. When asked for comment, Misty’s Head Shop Architect said, “Wait. What are we talking about?”

Additionally, we can report that our beta testers were exceptionally pleased with the performance of the system. “Unlike normal CAN bus systems, which leave you rage-posting over data loss, when our CAN-E-BUS network had issues, we just didn’t care.”

The QA department is currently completing their smoke tests at our lab here in Boulder, CO, with the first release of CAN-E-BUS scheduled for April 20th. CAN-E-BUS will be distributed where legally available.

Technical Specifications

Consumer level: Amateur to Pro

Primary usage: Medical and Recreational

Data transfer rate: 420 Mbps

Token length: N * 420 bytes

CAN-E-BUS DRAW message format:

All DRAW messages are generated by the Dispensary script and have a standard format, described below.

<Header>!<ID>!<THC>!<MT>!<Msg body>!<EOF>

Where:

Header = All CAN-E-BUS messages start with standard header DUDE. ID = Token owners’ identifier or broadcast using BRO. THC = The High Capacity bit: 1 — yes, 0 — no. MT = Message Type: MED, REC, EDBL, HS, etc. Msg body = Main context of message. Token bundles should be tightly sealed in escaping open/close ===*~~ / ~~*=== tags: ===*~~ YOUR_TOKEN_HERE ~~*=== EOF = All CAN-E-BUS messages end with standard EOF (End Of Frame) ROACH.

Example: