HEXABITZ - Modular Electronics for REAL

A new kind of electronic prototyping!

Similar projects worth following
This project is your introduction to Hexabitz, a new kind of modular prototyping platforms! Learn about the geeky hardware and software details behind the system and find your way to important links. Check our website: and don't forget to browse all the demo projects we will post here as well!Hexabitz is the outcome of years of prototyping and research. The project is still experimental but we're excited to share details and updates with all hardware geeks out there! We'd love to hear your feedback, ideas and what cool stuff Hexabitz would enable you to do! Enjoy.

Concept in a Nutshell

Hexabitz is a novel modular electronic prototyping system. Each module or bit comes in a specific shape or size. Either hexagon (hence the name Hexabitz), pentagon, rectangle, square or triangle. Modules are soldered together horizontally to make larger electronic boards or arrays. You can easily combine modules in any shape or configuration you want. The resulting board will be close to custom-made ones in terms of size, weight and form-factor.

Each Hexabitz module has a specific functionality and a small MCU on the back side. MCUs are used to connect modules together in a wired-mesh network and to execute various programs in parallel. Think "smart PCBs" where the small increase in cost and power consumption is dwarfed by huge gains in flexibility, scalability and reusability. 

What's Different About Hexabitz?

Here's a run-down of the most differentiating characteristics of Hexabitz:

  1. Form-Factor: Hexabitz nature-inspired form-factor emphasizes horizontal integration since it is the default mode of construction for custom-made PCBAs and electronics. This makes Hexabitz prototypes more real-life ready than many other platforms.
  2. Dust Computing: Hexabitz does not follow the traditional model of a single motherboard (controller) and 'dump' daughter boards that has been around since the advent of micro-computing. We believe computing is cheap and small enough these days that it should be embedded in each PCB. All our modules -except the very simple power sources- feature a small and low-power Cortex-M0 MCU. Future high-performance implementations will probably feature FPGAs and other logic blocks.
  3. The Wired-Mesh: Standard electrical buses impose topology and capacity limitations that destroy modularity. Hexabitz is based, instead, on a wired-mesh, decentralized network concept. Pioneered by wireless sensor networks, mesh connectivity provides ultimate modularity and a more scalable system. Coupled with Hexabitz nature-inspired form-factor, the wired-mesh enabled us to put a much larger number of modules together (> 5 times more than other platforms) and still keep a small footprint.
  4. Distributed System: A side benefit of 2 and 3 is that you get a truly parallel and distributed system. Hexabitz application development is a little bit different than standard embedded systems: you emphasize connectivity and think about your application more holistically, breaking into separate chunks that run in-parallel on separate modules.
  5. Stand-Alone: Since all configurable Hexabitz modules come with their own MCU, they act as stand-alone development boards that can be used without any external controllers. You can access module functionality by using the Command Line Interface (CLI) and directly connecting to a PC or triggering actions with external buttons / switches. Eliminating the need for external controllers can reduce overall system size and cost in many applications.
  6. Automation-Ready: The current hardware implementation of Hexabitz is the most abstract one, geared more toward production than a plug-n-play system. On top of this implementation, one can introduce multiple layers of add-ons that customize the platform for different applications (connectors, magnets, attachments, stress-relief mechanisms, etc.) One of the benefits of the abstract implementation is that arrays can be assembled automatically by pick-n-place machines and soldered by robots, providing opportunities for future automated prototyping factories or even a desktop-size prototyping machine.

Where to Start?

Read the following logs for a primer on Hexabitz hardware and software architecture. Check the gallery of photos and videos on Hackaday and on our website. Also check the FAQ section and learn about the inspiration behind Hexabitz and our future plans....

Read more »

H08R60 Factsheet.pdf

H08R60 (H23R00) Factsheet

Adobe Portable Document Format - 857.18 kB - 05/15/2018 at 02:45


H01R00 Factsheet.pdf

H01R00 Factsheet

Adobe Portable Document Format - 844.24 kB - 05/15/2018 at 02:31


H05R00 Factsheet.pdf

H05R00 Factsheet

Adobe Portable Document Format - 854.19 kB - 05/15/2018 at 02:31



BOS Factsheet

Adobe Portable Document Format - 795.95 kB - 05/15/2018 at 02:31


H09R00 Factsheet.pdf

H09R00 Factsheet

Adobe Portable Document Format - 764.81 kB - 05/15/2018 at 02:31


View all 22 files

  • Code Overview 8: Array Exploration

    Hexabitz06/03/2018 at 23:40 0 comments

      Array exploration is a feature that lets automatically configure your Hexabitz arrays and generate their topology without a sweat. It is particularly useful for large and complex arrays where manually generating the topology is usually cumbersome and error-prone.

      Once you assemble your array and program all modules with native firmware, You can invoke the array exploration algorithm via the Explore() API or explore CLI command. The algorithm finds out number of connected modules (N), the topology routing table (stored in array matrix) and which ports are swapped. All of these information are stored either in the emulated EEPROM or a special Flash page so that you don't have to explore again every time you reboot the array. Note that the module you're connected to when invoking the exploration algorithm will be assigned ID #1. Other modules will be assigned sequential IDs based on their relative distance to the master (module #1).

      Exploration Algorithm

      Here's a detailed step-by-step description of what happens in the exploration algorithm:

      1. The master module (ID #1) swaps all its ports and explores adjacent neighbors by sending them an inquiry message. Neighbors send back a response mentioning which port they heard the inquiry from. 
      2. The master then starts assigning IDs to new modules and updating its topology array:
        1. Assign sequential IDs to neighboring modules (according to master ports they're connected to).
        2. Update the master topology array with IDs and ports of neighboring modules.
        3. Ask neighbors to update their own topology array.
      3. The master asks each new module to explore its neighbors, basically repeating steps 1 & 2. This continues level by level until all modules are explored:
        1. Master asks a given module to swap its ports
        2. Master asks the module to explore its adjacent neighbors.
        3. Master assigns IDs to this module adjacent neighbors.
        4. Master updates its topology array.
        5. Master asks all discovered modules to update their topology array as well. Then the master repeats steps 1 to e asking nex module down the list to explore.
      4. The master ensures all connected modules have been already discovered by reissuing exploration commands to all modules and watching out for any new un-IDed modules.
      5. If there are no un-IDed modules, the master generates and distributes appropriate port directions:
        1. Virtually reset the state of master ports to Normal.
        2. Update other modules ports starting from the last one and going backwards to ensure the communication chain is not broken.
        3. The master asks each module to update its port direction.
        4. The master officially updates its ports back to normal.
      6. The master tests new port directions by pinging all modules and recording their responses. It's also displayed on the terminal if the CLI explore command was invoked.
      7. The master asks all modules to save the topology and port directions in specific Flash page (for topology) and emulated EEPROM (for number of modules and port directions).

      The following video shows exploration of different arrays with various shapes and complexities. There are generous delays currently in the algorithm making it a bit lengthy (2 minutes for the sphere) but they can be optimized later.

      Removing Current Topology

      If you want to reconfigure the array in a different shape without erasing and reprogramming modules, you can invoke the CLI command default array to remove topology related information from Flash / emulated-EEPROM. Remember to do that before disassembling you array!

  • CR2032 Coin-cell Battery Holder Modules (H04R10 / H04R20)

    Hexabitz04/14/2018 at 03:36 0 comments

    H04R10 / H04R20 are compact coin-cell lithium battery holders that fit two CR2032 batteries in parallel (H04R10) or in series (H04R20).The output voltage is provided through Hexabitz SMD edge-pad connectors (3.0V in H04R10 and 3.3V in H04R20 on top and GND on bottom).

    Note 1: H04R10 was named H13R00 before. 

    Note 2: H04R20 was named H13R10 before. 

    Note 3: These modules do not ship with coin-cell batteries.

    Technical Specifications

    • 2 x CR2032 lithium coin-cell battery holders in parallel (+3.0V output) in H04R10.
    • 2 x CR2032 lithium coin-cell battery holders in series (+3.3V output) in H04R20.
    • Six power ports (+3.0V/+3.3V and GND).
    • 2 x BLP2032SM-GTR SMD coin-cell holder with gold-plated contacts.
    • H04R10: BAT54JFILM 40V 0.3A reverse current protection Schottky diode. (Can be shorted with a solder jumper.)
    • H04R20: TPS76433DBVT 3.3V 0.15A LDO.

    Physical Properties

    • Shape: Hexagon
    • Size: 3 cm short diagonal
    • Area: 7.8 cm^2
    • Soldermask Color: Dark green
    • Finish: ENIG (gold) or HASL-LF (tin)


    Design Files

    • H04R10 schematics [PDF]
    • H04R20 schematics [PDF]


    Q: How much current do I get from a single H04R10?

    A: Most CR2032 coin-cell batteries are about 200mAh capacity with a standard discharge current of 0.2mA. With two in parallel, you can get up to 450-500mAh of each H04R10 module.

    Q: What happens if I have another higher voltage source in my board?

    A: There is a reverse protection Schottky diode on H04R10 that prevents current from flowing back into the coin-cell battery in case you have higher voltage (e.g., 3.3V or 5V) applied at the same time. Note that although Schottky diodes have low forward voltage drop, the drop can reach 300mV at the above battery discharge rate. To avoid having a lower output voltage (3-0.3 = 2.7V), you can short the reverse protection diode on H04R10 with a solder jumper.

    Q: How much current do I get from a single H04R20?

    A: Most CR2032 coin-cell batteries are about 200mAh capacity with a standard discharge current of 0.2mA and voltage of 3V. With two in series, you can get same capacity but double the voltage. The voltage is regulated back down to 3.3V to be compatible with other Hexabitz modules. You can also solder H04R20modules together, connecting them in parallel, to get more capacity.


  • Micro-SD Memory Card Module (H1BR60)

    Hexabitz04/14/2018 at 03:28 0 comments

    H1BR60 is a nifty little SPI-based, micro-SD card module based on STM32F0 MCU and running Fatfs file system. It is part of the upcoming Hexabitz modular prototyping system.

    • Use as a stand-alone data-logger or easily integrate with other hardware via serial interfaces.
    • Setup and control logging via a Command Line Interface (CLI).
    • Log digital inputs, memory locations, program variables, serial streams and button actions.
    • Start multiple simultaneous logs with different log variables each.
    • Firmware has Fatfs embedded file system and advanced logging functionality (event logs, rate logs, sample-based, time-based, sequential naming, etc.)
    • Supports SDHC micro-SD memory cards (FAT32, up to 32GB size).
    • Program advanced C code with our easy-to-use APIs.
    • Connect to external hardware or combine with other Hexabitz modules!

    Note 1: This module was named H05R00 before.

    Note 2: This module does not ship with a micro-SD card.

    Technical Specifications

    • Five array ports and four power ports (+3.3V and GND).
    • Access to 5xUART, 1xI2C, SWD, BOOT0, RESET.
    • SPI-connected microSD memory card for SD and SDHC cards with full integration of Fatfs file system.
    • Molex 502570-0893 microSD push-push connector with card detection.
    • STM32F091CBU6 MCU.
    • 8MHz external oscillator.

    Physical Properties

    • Shape: Hexagon
    • Size: 3 cm short diagonal
    • Area: 7.8 cm^2
    • Soldermask Color: Dark green
    • Finish: ENIG (gold) or HASL-LF (tin)


    Design Files

    • Module schematics [PDF]

    Source Code


    Q: How do I use H1BR60 to add logging capability to my projects?

    A: H1BR60 module logs all sorts of signals connected to its array ports. You can stream digital data from external hardware using serial ports (UART), connect digital sensors (3.3V max) directly, connect external switches of any type (mechanical, optical, magnetic) or momentary and toggle buttons.

    Q: Can I log same signal in different ways?

    A: Yes! You can start two simultaneous logs of different types (rate or event) and log same or different signals.

    Q: Can I log a complicated condition/combination of signals?

    A: Yes! You can write C code to combine signals in complex ways and write the output to an internal RAM buffer. This buffer / memory location can then be logged either on rate- or event-basis.

    Q: What's the maximum logging rate in H1BR60?

    A: Maximum logging rate is 1KHz. However, it depends on number of simultaneous logs and number of variables per log. Usually it is several hundred Hz in complicated scenarios.


  • 120/240VAC-1.2A Solid State Relay Module (H0FR60)

    Hexabitz04/14/2018 at 03:22 0 comments

    H0FR60 is a compact solid state relay (SSR) module capable of driving AC loads up to 600V and 1.2A. It is based on Panasonic AQH3213A SSR and STM32F0 MCU. It is part of the upcoming Hexabitz modular prototyping system.

    • Use as a stand-alone smart AC relay and easily control AC loads (lamps, fans, power outlets, etc.) via a Command Line Interface (CLI).
    • Firmware has embedded on / off / toggle, timers and PWM functionality.
    • Program advanced C code with our easy-to-use APIs.
    • Connect many H0FR60 modules together and build interesting flat and curved boards with any configuration you imagine!
    • Send commands to a single relay, a group of relays or broadcast to all of them.
    • Connect to external hardware or combine with other Hexabitz modules!

    Note: This module was named H09R00 before.

    Technical Specifications

    • Five array ports and six power ports (+3.3V and GND).
    • Access to 5xUART, 2xI2C, SWD, BOOT0, RESET.
    • Panasonic AQH3213A solid-state relay (SSR):
    • 120V or 240V AC rated voltage.
    • 600V AC peak OFF-state voltage.
    • 1.2A ON-state RMS current.
    • 100 µsec maximum turn-on time.
    • Zero-crossing detection.
    • Yellow indication LED for SSR state.
    • SSR load connector: TE Connectivity/AMP 2-position 5.08mm shrouded header.
    • STM32F091CBU6 MCU.
    • 8MHz external oscillator.

    Physical Properties

    • Shape: Hexagon
    • Size: 3 cm short diagonal
    • Area: 7.8 cm^2
    • Soldermask Color: Dark green
    • Finish: ENIG (gold) or HASL-LF (tin)


    Design Files

    • Module schematics [PDF]

    Source Code

    • Coming soon!


    Q: What types of loads you can switch with this SSR?

    A: All sorts of AC loads < 700 watts including lamps, fans, heaters, power outlets, AC synchronous motors, etc. You can also switch DC loads in the same range (but this SSR will not stop a DC load going the other direction unless you turn it off).


  • 3.3V / 1A DC-DC Buck Power Module (H03R00)

    Hexabitz04/14/2018 at 03:16 0 comments

    H03R00 is a compact DC-DC buck power supply with a 3.3V/1A DC output and 5-40V DC input. The output voltage is provided through Hexabitz SMD edge-pad connectors (3.3V on top and GND on bottom). The -T module version comes with a 5.08mm terminal block connector for input voltage. This module is part of the upcoming Hexabitz modular prototyping system and can be used to power all your Hexabitz arrays as well as other hardware.

    Technical Specifications

    • Input voltage: +5V to +40V DC.
    • Output voltage: +3.3V DC.
    • Output current: 1A.
    • Six output power ports (+3.3V and GND).
    • TI LM2575SX-3.3/NOPB high-efficiency, 1A, step-down, switching voltage regulator:
    • 52 kHz Fixed Frequency Internal Oscillator.
    • Thermal shutdown and current limit protection.
    • Green power-OK LED.
    • Input voltage connector: TE Connectivity/AMP 2-position 5.08mm shrouded header.

    Physical Properties

    • Shape: Hexagon
    • Size: 3 cm short diagonal
    • Area: 7.8 cm^2
    • Soldermask Color: Dark green
    • Finish: ENIG (gold) or HASL-LF (tin)


    Design Files

    • Module schematics [PDF]


    Q: How many Hexabitz modules I can power from a single H03R00?

    A: Depends on type of modules connected but usually 40+ modules can be powered from a single H03R00.

    Q: How can I access output voltage for non-Hexabitz hardware?

    A: You can solder wires and many types of connectors to the SMD edge pads. Our favorite one is the 2-pin 2.54mm male header which fits there perfectly but other connectors are also possible.

    Q: Can I combine multiple H03R00 modules on parallel to get higher current?

    A: Theoretically you can do so as the edge PCB connectors are perfect to connect modules on parallel. However, be careful as sometimes small variations in output voltage might cause current to flow from one power supply to another. We will have in the future dedicated modules to handle load-sharing between power supplies!


  • RGB LED Module (H01R00)

    Hexabitz04/14/2018 at 03:13 0 comments

    H01R00 is a smart RGB LED module based on Cree CLVBA-FKA-CC1F1L1BB7R3R3 RGB LED and STM32F0 MCU. It is part of the upcoming Hexabitz modular prototyping system.

    • Use as a stand-alone smart RGB LED and easily control via a Command Line Interface (CLI).
    • Firmware has embedded on / off / toggle, PWM, dimming and color sweep functionality.
    • Program advanced C code with our easy-to-use APIs.
    • Connect many H01R00 modules together and build interesting flat and curved boards with any configuration you imagine!
    • Send commands to a single LED, a group of LEDs or broadcast to all of them at the same time.
    • Connect to external hardware or combine with other Hexabitz modules!

    Technical Specifications

    • Six array ports and six power ports (+3.3V and GND).
    • Access to 6xUART, 2xI2C, SWD, BOOT0, RESET.
    • Dominant Wavelength: Red (619 - 624nm) Green (520 - 540nm) Blue (460 - 480nm).
    • Luminous Intensity (mcd) @IF=20mA: Red (224 - 560) Green (280 - 900) Blue (90 - 355).
    • STM32F091CBU6 32-bit ARM Cortex-M0 MCU.
    • 8MHz external oscillator.

    Physical Properties

    • Shape: Hexagon
    • Size: 3 cm short diagonal
    • Area: 7.8 cm^2
    • Soldermask Color: Dark green
    • Finish: ENIG (gold) or HASL-LF (tin)


    Design Files

    • Module schematics [PDF]

    Source Code


    Q: Isn't a 32-bit MCU an overkill for a smart LED module?

    A: Yes! But all Hexabitz modules -whether it's a complex Ethernet or IMU or a simple LED- share same backend hardware and software. This what gives the platform its unmatched modularity and scalability. Cortex-M0 MCUs are small, cheap, power-efficient, yet capable of really wonderful things. Having an embedded MCU provides a cheaper and more compact alternative to connecting an LED breakout with an external controller.

    Q: What level of soldering experience is required?

    A: Hexabitz are designed for the absolute soldering beginners! The edge pads are large and easy to reach and anyone with basic knowledge of soldering can assemble a flat array. Curved and spherical arrays require more training but can be made easier with 3d-printed fixtures.


  • Code Overview 7: Real-time Clock and Calendar

    Hexabitz04/03/2018 at 04:02 0 comments

    Each programmable module has a real-time clock (RTC) and calendar that can be used to track time and date. The module will maintain an accurate internal time and date as long it is powered from a power source or battery and the initial time and date were setup correctly.

    Current time and date can be accessed anywhere in the project by calling the GetTimeDate() API and reading the global BOS.time and structs:

    BOS.time.ampm      // Current time in 12-hour format: RTC_AM or RTC_PM
    BOS.time.msec      // Milli-seconds: 0-999
    BOS.time.seconds   // Seconds: 0-59
    BOS.time.minutes   // Minutes: 0-59
    BOS.time.hours     // Hours: 0-23       // Date: 1-31     // Month: JANUARY (1) to DECEMBER (12)   // Weekday: MONDAY (1) to SUNDAY (7)      // Year: Starting from 2000

    You can setup the hour format (12 or 24) and calendar daylight saving settings (DAYLIGHT_SUB1H, DAYLIGHT_ADD1H, or DAYLIGHT_NONE) from the BOS.hourformat and the BOS.daylightsaving parameters, respectively. The settings will be saved in the emulated-EEPROM and loaded on startup.

    The RTC takes firmware compile time and date as the initial time and date by default. You can reset the initial time and date via the BOS_CalendarConfig() API. Even if the MCU was hardware-reset, it will keep its current initial time and date (and thus maintain time and date accurately) as long as it is powered. Once it loses power, it returns to the default firmware compile time and date and the RTC must be reconfigured again.
    To display current time and date in the CLI, use the time and date commands. You can also configure the RTC in the CLI via the set command.

  • Code Overview 6: Remote Memory Access

    Hexabitz04/03/2018 at 03:59 0 comments

    BOS offers a powerful remote memory read/write access functionality through specific Messages and APIs. This allows a module to access and modify almost any RAM or Flash memory location in another module in the array thus providing powerful synchronization and granular control.

    BOS Variables

    Typically, you will need a valid memory address to read a variable stored in RAM (e.g., 0x20000100) or Flash (e.g., 0x08000100). In order to simplify the process, BOS defines a set of RAM-based BOS Variables that you can use to easily exchange small amount of data across the array. BOS Variables can be addressed with easy-to-use virtual addresses (1 to N) without the need to know their actual RAM location. For example, you can link a float (or any other datatype) value to BOS Var 1 and access it from any other module in the array. There is a maximum number of bytes that each module reserve for BOS variables. It is defined in MAX_BOS_VARS preprocessor constant. If MAX_BOS_VARS=100, then you can define 100 1-byte variables, or 25 1-word variables and so forth.
    The following examples demonstrate how to define BOS variables. Using the keyword volatile in front of a variable definition tells the compiler that this variable might change outside the program (e.g., by a remote module):

    // LED state (ON/OFF), intensity and color (global or static if inside a function)							
    volatile bool state = true; 	            
    volatile uint8_t intensity = 50, color = WHITE;	
    // Link to BOS variables (inside a function)	
    AddBOSvar(FMT_BOOL, (uint32_t) &state);
    AddBOSvar(FMT_UINT8, (uint32_t) &intensity);
    AddBOSvar(FMT_UINT8, (uint32_t) &color);

    The API AddBOSvar() accepts the following datatypes:


    and returns the BOS variable index (or virtual address) or 0 if memory is full.
    Note 1: BOS variables must be defined as global (e.g., outside a function) or static to ensure we do not reference a temporary variable within a function stack.
    Note 2: When using direct Flash and RAM addresses, pay special attention to memory alignment. Cortex-M0 MCUs do not accept non-word aligned memory access, which results in a processor Hardfault.

    Remote Read

    Use the ReadRemoteVar() and ReadRemoteMemory() APIs to read a remote module BOS variable or memory location. The first one returns a pointer to the remote value as well as a pointer to the remote BOS variable format. The second API only returns a pointer to the remote value. The remote format here should be specified by the local module since a memory location can contain any datatype. Note that the returned pointers must be casted to the correct datatype before their addressed value can be read correctly. The following examples demonstrate the proper use of these APIs:

    volatile float myremotevar = 0;
    // Reading remote address 0x2000001c from Module 2 with FLOAT format and 1000ms timeout
    myremotevar = *(float *)ReadRemoteMemory(2, 0x2000001c, FMT_FLOAT, 1000);
    volatile bool mybool;
    varFormat_t format1;
    /* Reading remote BOS variable 1 from Module 2 with 100ms timeout. Remote format is requested and stored in format1. It can be used to cast the variable properly in case we don't know the format beforehand */
    mybool = *(bool *)ReadRemoteVar(2, 1, &format1, 100);

    Both read APIs will block until the read value is returned or timeout reached (in which case a NULL pointer is returned). If he requested remote BOS variable does not exist, the APIs return BOS_ERR_REMOTE_READ_NO_VAR.

    Remote Write

    The API WriteRemote() is used to write to both a remote memory location or BOS variable. Setting up the remoteAddress parameter to any value between 1 and MAX_BOS_VARS writes to a BOS variable while setting it up to a valid RAM or Flash location writes to this location. If the BOS variable does not exist, a new one will be created in the remote module. The remote format is always specified by the local module. The following examples demonstrate the API usage:

    Read more »

  • Code Overview 5: Project Structure

    Hexabitz04/03/2018 at 03:53 0 comments

    Hexabitz software is released as a compiled HEX file and a uVision project along with source files for each module. The project folder contains the following subfolders:

    • BOS: Contains source files for the BOS.
    • H01R00 (or other PN): Contains source files for this module.
    • MDK-ARM: Contains uVision project files as well as output files (assembler output, linker output, compiler output, etc.)
    • Thirdparty: Contains source files for other libraries used in the project (e.g., HAL, FreeRTOS, etc.)
    • User: Contains user-modified files used for this particular array/project. This folder includes main.c that contains the FrontEnd Task, the topology header files and the project header file project.h.

    Updating to Latest Release

    It is always recommended to update your projects to latest software release to get new features and bug fixes. Check release notes here for details on each release. To update your project to latest release, simply keep the user folder and replace all other folders with those in the release Dropbox. To maintain this level of portability, you should try to keep all your custom code in main.c and project.h files.

  • Using the Command Line Interface (CLI)

    Hexabitz04/03/2018 at 03:46 0 comments


    Use your favorite serial terminal emulator tool to access the serial COM port of your computer and thus Hexabitz CLI via a USB-to-UART cable. Some examples include RealTerm, Putty, HyperTerminal and SecureCRT. The configurations displayed here are for RealTerm but they are similar to those in other terminal emulators.
    If you use standard FTDI USB-UART 3.3V cable for power and communication, connect the colored cable wires as follows:

    • Red to 3.3V (top power pad, i.e., corner edge pad).
    • Black to GND (bottom power pad, i.e., corner edge pad).
    • Yellow to TXD (top communication pad, i.e., side edge pad).
    • Orange to RXD (bottom communication pad, i.e., side edge pad).

    RealTerm Configurations

    In RealTerm Display tab, select Ansi as data display mode. This mode allows you to use the BACKSPACE key to delete previous characters. Optionally, enable Scrollback and increase number of Rows to a suitable number (e.g., 32).
    In the Port tab, select 921600 baudrate and open the appropriate COM port. The port will only show up after you power the module and usually it will have \VCP (virtual COM port) in its name.

    Once you open the port, press the ENTER keyboard key to start the communication session. You should see the CLI welcome message shown below. It tells you the ID of the module you are connected to and through which array port. Note if the module is native, i.e., not part of an array via a fixed or explored topology, it will show up as ID = 0 (unless you change default ID in the code).

    Setting up Baudrate

    Default baudrate for all array ports is 921600. You can change this rate with the following methods:

    1. Connect P1 TXD and RXD together momentarily while power-cycling the module. This will setup all array ports to 115200. Once you connect to a CLI port, other messaging ports restore their default baudrate. Note that the CLI will restore its default baudrate on the next power cycle.
    2. Change the value of BOS.clibaudrate parameter in the CLI using set Command. This will save the value to the emulated EEPROM so that you can use the new baudrate each time. You need to reset the module to apply the new baudrate. Note that similar to method 1, the new baudrate will apply to all ports until you connect to the CLI.
    3. Change the value of BOS.clibaudrate parameter in the code and call this API UpdateBaudrate(port, baudrate) to apply the new baudrate to a given port. You can also save it to EEPROM using this code (It will be loaded automatically from EEPROM on each startup):
    EE_WriteVariable(VirtAddVarTab[_EE_CLIBaud], (uint16_t)BOS.clibaudrate);
    EE_WriteVariable(VirtAddVarTab[_EE_CLIBaud+1], (uint16_t)(BOS.clibaudrate>>16));

    If you want to restore the default CLI baudrate, you can either:

    • Set BOS.clibaudrate to default value either in CLI or in code as shown above.
    • Initiate a Factory Reset by connecting P1 TXD to programming port RXD or to last port RXD while power-cycling the module.
    • Set all parameters back to default using default params Command or the following code:
    memcpy(&BOS, &BOS_default, sizeof(BOS_default));

    General Usage Tips

    • Type help anytime to view the list of Commands enabled in this module (and this firmware). You can figure out the firmware version and compile time and date using the status Command.
    • If you misspell a Command you can use the BACKSPACE keyboard key to delete last characters and replace them with correct ones as long as you have not pressed ENTER yet. BACKSPACE does not actually work in the terminal window as in a text editor but it will still work fine with the CLI. You cannot clear a character from the terminal window for example. When you press BACKSPACE, the blinking cursor will move back one step but the previous character will stay displayed. It will be removed, however, from CLI buffer. If you write a new character, it will replace the old one on the terminal window and it will be added to the CLI buffer.
    • If you misspell a Command and press ENTER, it will be ignored and you will...
    Read more »

View all 22 project logs

Enjoy this project?



Keith Olson wrote 06/22/2018 at 17:19 point

Great project!  Some suggestions:
1. SG90 servos would fit within the 30mm limit of a hex board, though I'm not sure if the necessary ~15x12mm, pear-shaped hole in the middle of the board would physically interfere with the STM32F0 MCU.  Maybe have the board use a double-hex shape?
2. Create a 'comb' PCB with unconnected pads around the slots to allow stacking boards.  Offer different spacing for the slots to accommodate different component heights.  Additionally/alternatively, create STL's to line up/support stacked boards.

Hope these help!

  Are you sure? yes | no

Hexabitz wrote 06/23/2018 at 02:58 point

Thanks for the great feedback!

1. Yes I agree! Servo drives are in the roadmap but we haven't considered yet putting the actual motor there. I think this'd be awesome.

2. Yes definitely in the roadmap. Both SMT and through-hole extension board. We're also planning "empty" proto modules (SMT and TPH) so that you can make your own simple one. This one is coming hopefully in a few months but we're prioritizing ther software dev for now. Feel free to send any other great suggestions!

  Are you sure? yes | no

Pham Thanh Trung wrote 03/29/2018 at 17:21 point

May I join this project ? Do you have any requirement ?

  Are you sure? yes | no

Hexabitz wrote 03/30/2018 at 22:32 point

Thank you for your interest! We're not planning to expand the team right now but feel free to message us with details about yourself and your experience :)

  Are you sure? yes | no

hazem wrote 03/25/2018 at 06:16 point

Great idea! .... Keep it up

  Are you sure? yes | no

Mohanad Kaleia wrote 03/23/2018 at 17:12 point

Such a great project. I believe that Hexabitz will shape the future of hardware design

  Are you sure? yes | no

Hexabitz wrote 03/24/2018 at 03:01 point

Thanks Mohannad! I'm trying in this project to move focus from hardware to software so that people with software experience can build awesome electronics as well :)

  Are you sure? yes | no

malvasio.christophe wrote 03/23/2018 at 07:58 point

missing electric generators
look at to make some for low cost

  Are you sure? yes | no

zakqwy wrote 03/22/2018 at 17:16 point


  Are you sure? yes | no

Hexabitz wrote 03/23/2018 at 05:41 point

Thanks @zakqwy ! Your NeuroBytes project is so awesome as well! Let me know if you've got feedback for us. We're working our way through more module and projects.

  Are you sure? yes | no

zakqwy wrote 03/24/2018 at 12:58 point

sure! I could drone on for some time; one thing that comes to mind is that project complexity doesn't scale linearly with the number of unique modular designs, it's something more severe and exponential. keep that in mind when you are deciding which designs to take into production. I advise minimizing the crossover between modules whenever possible.

  Are you sure? yes | no

Hexabitz wrote 03/24/2018 at 17:46 point

I agree! Scaling software up is really difficult and also having MOQs of multiple modules is expensive. But you can't do lots of interesting projects without variety of modules. Still trying to learn how to balance these.

  Are you sure? yes | no

Duke Circuit Co.,Ltd wrote 03/17/2018 at 03:42 point

the shape like a map,good job.

  Are you sure? yes | no

Hexabitz wrote 03/17/2018 at 07:33 point


  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates