This page is mainly for the benefit of users who received an early board to try. I will add information here as soon as I'm aware of something you need to know that I forgot to mention.

Currently there is very little documentation on node types and their properties. Feel free to ask about some specific node or goal that you're trying to achieve, this will help to know which areas of the documentation to focus on first.

Account setup: https://iomixer.com/account (only necessary to save your configurations online, or to use the forums)

Configurator: https://iomixer.com/configurator

Binaries: https://iomixer.com/releases (relay server, firmware and bootloader)

How to update firmware: https://youtu.be/O6NVy6e5CBQ

Tutorial: https://youtu.be/-yt7LyJZxn8

Forums: https://iomixer.com/forums

PCB assembly files (v1.2 board): https://iomixer.com/pcba

PCB assembly overview: https://youtu.be/BKhxOeRhcWc (ordering from JLCPCB, flashing bootloader and firmware, activating)

The are two types of early prototype board, v1.1 and v1.2, labelled on the underside. These can also be differentiated by the crystal/oscillator type (black on v1.1, silver on v1.2) and the added button on v1.2.

These board revisions require different firmware, so please make sure to pick the correct files when flashing the firmware or bootloader.

The relay server is a command line program that requires no parameters or setup. An example of starting it up can be found in the tutorial video at 0:56.

On Linux and MacOS: you will probably need to make the relay server an executable file after downloading it. You can do that with "chmod +x <filename>".

When using the Safari browser you will find that Safari will not connect to the relay server when using https in the URL (eg. https://iomixer.com). Whether this is a bug or not seems to be an ongoing point of contention (https://bugs.webkit.org/show_bug.cgi?id=171934). One workaround is to use http instead of https, although you will then not be able to use features that require logging in (activating a board, and saving your configs in the database). Another workaround is to use just about any other browser.

When using Brave browser you will need to enable localhost permission as described in the footnote here. At least, that's what they say, but I could not find any such options in the settings, even on v1.60 when this feature was supposed to be introduced in v1.54 (https://github.com/brave/brave-browser/issues/31689). Another option seems to be click on the shield icon next to the address bar, and in 'Advanced controls' select 'Allow trackers and ads'.

The prototype boards have been sent in non-activated state, meaning that most input and output nodes will be disabled. To activate your board, make an account and let me know to add a credit for you. Then you can use the configurator to do the activation.

An example of activating a board can be found in the tutorial video at 6:56 and in the assembly overview video at 26:57.

The iomixer can be powered via the micro-USB connector, or by applying 5V - 15V to any of the red pin headers. It is safe to use both at the same time.

Pins labelled VCC means 3.3V.
Pins labelled VIN means whatever voltage is on the red headers.
DO NOT connect red pins to yellow pins!!
DO NOT connect any signal pins (white ones) to red pins!! (Actually, some of the signal pins are 5V tolerant, but better to be safe than sorry)

When powered by USB only, the voltage on the red headers will be around 4.7V which is often sufficient to run RGB LEDs and an (unloaded) small servo or two.
For larger loads you will want more than just USB power. The traces for the VIN net should be able to handle 4A, for higher currents please route the power lines externally.

The onboard RGB LEDs can be connected to red pin headers (VIN) with the solder bridge next to them.
If you use more than 5V on the red headers, the solder bridge for the RGB LEDs should be left disconnected to avoid damaging them.

The pins used for analog input (18-23) have 3.3V (yellow pins) instead of 5V. This is to make it easier to connect potentiometers, where the sensed voltage must range from 0 - 3.3V. When you connect a potentiometer, make sure to use a yellow pin for the positive, NOT a red pin.

Normally when iomixer starts up, it loads the stored configuration and runs it. To skip this step and use an empty configuration, you can hold pin 40 high while powering up the board. This may be useful in the event that some combination of nodes triggers a bug, and the stored config needs to be abandoned.

Note that Pin 40 does not have a breakout header, it is only connected to the blue LED.

To hold pin 40 high on a v1.2 (or later) board, just hold down the little button.

On a v1.1 board, connect a jumper wire to one of the 3.3V pins (yellow headers) and carefully touch the other end on the bare pad next to the blue LED while power cycling. Do not use red headers for this. Unfortunately the "40" text ended up under the solder pad but you can still see it just a little:


For those few people who have an older v1.0 board, there is no bare pad but you can touch the 3.3V onto the one side of the blue LED, nearest to the microcontroller.

When the stored program is successfully ignored, the red and blue LEDs will both flicker quickly for about one second on startup.

Please note that the stored program is still stored, so ignoring it is a temporary state that only affects one startup. If you power cycle the board again without holding pin 40 high, the stored program will again be run as normal.

Bootloader mode is used to update the firmware. There are two ways to enter bootloader mode.

1. In the Firmware panel, click "Toggle bootloader on restart" and power cycle the board.
2. Hold pin 40 high while power cycling as mentioned in 'Ignoring the stored program' above, three times in a row.

Bootloader mode will also run if the board is newly assembled and has the bootloader flashed, but the firmware has yet to be flashed.

In bootloader mode the blue LED will flash twice at about a one second interval. To return to normal, just power cycle again.

Files for firmware update must be placed in the working directory of the relay server.

To update the firmware, go to the firmware panel and enter bootloader mode as mentioned above. Select the firmware file to flash and click "Flash firmware". Wait for completion and then power cycle.

An example of flashing the firmware can be found in the assembly overview video at 24:24.

Currently only μ-blox UBX protocol input is supported. The required configuration of the GPS module can be done automatically, and optionally saved so that no configuration is needed next time. These modules have been tested: M8N, M8P, 7M, 6M, BN452/M9N, BN880, BN220, BN180.

The onboard IMU uses the default I2C address for MPU6050. In order to use a second IMU, it will need to have its address pin jumpered so that the I2C addresses do not clash, and each IMU node in the configuration will need to specify which IMU should be used. The same applies for I2C barometers and compasses.

Up to 128 addressable LEDs can be used in one string. To use the 3 onboard LEDs a solder bridge can be used to power them, with no more than 5V applied to the red headers.

The WS2812 protocol is used to control the LED strip. These are intended to be run with 5V signals but in practice many of them also work fine with a 3.3V signal. This is not guaranteed though. The onboard LEDs should be fine.

The outputs referred to as 'display' are various small screens, some pictured below. The easiest ones to use will be those with a pin ordering that matches the headers, ie for I2C: (GND VCC SCL SDA) and for SPI: (GND VCC CLK MOSI RES DC CS). Currently the supported drivers/screens are:

• SSD1306 128x64 (I2C)
• SSD1306 128x32 (I2C)
• SSD1331 96x64 (SPI)
• ST7735 128x128 (SPI)
• ST7735 128x160 (SPI)
• ST7735S 160x80 (SPI)

The displays can only show text, always 8 pixels per line, one line per 'display' node. The value can be prefixed with a label and given some basic formatting such as maximum decimal places. These lines of text are updated at 50Hz, one line per loop taking turns. So for example if you have 5 lines as in the photo below, each line will be updated at 10Hz.

The default USB device enumeration when plugged into a computer is a STM32 Virtual Com Port, for communication with the relay server. This can be changed to become a composite USB device for simultaneous use as a gamepad and VCP. On Linux this requires no extra setup, and on Windows the device can be manually specified as composite device pretty easily.

On MacOS composite device detection seems to be rather problematic so a third option is available, to become purely a gamepad. This works well as a gamepad but takes away the ability to communicate with the relay server.

To choose the device mode, select it from the pulldown list in the Gamepad panel and click "Set USB class".

To temporarily revert back from gamepad-only mode to the default USB device type (VCP only), ignore the stored configuration on startup as mentioned above.

To use MIDI over USB (firmware v0.1.3 onwards) you will need to set the USB class to 'VCP + MIDI', in the same way as mentioned above for a gamepad.

For older MIDI devices (those with MIDI in/out DIN ports) these can used over a UART connection. A proper MIDI circuit is supposed to use a photodiode circuit, but this is not present in iomixer. I've had mixed success with treating the input as a normal UART RX. My Akai MPD232 works great, but I spent many hours trying to get a M-Audio Keystation to give any MIDI output on the DIN plug.

Some features have more restrictions on which pins they are able to use. For example any pin can be a digital input or output, but an nRF24L01 or SPI display must use specific SPI pins. To ensure that less flexible features are catered to first, there is a 'pecking order' to decide which features have priority for pin usage. In the list below, features higher in the list can make pins unavailable for those below them.

1. nRF24
2. UART
3. Rotary encoder
4. PPM input
5. Analog input
6. Servo PWM input
7. Digital input


8. RGB LED output
9. Display output
10. Duty cycle PWM output
11. PPM output
12. Servo PWM output
13. Digital output

The features panel lists features in their priority order, along with the current pin allocation status. In the image on the left, servo PWM input requires specific pins and therefore has priority over digital input. Pins 9 and 10 are shown in green to indicate they are good to go for servo PWM. Likewise the digital input using pin 8 has no conflict, also green. Pin 9 has also been selected for use as a digital input but conflicts with a higher priority feature, so is shown in red along with the name of the other feature it conflicts with. There are no conflicts for pin 10, but since it has already been allocated by a higher priority feature, is shown in orange as a reminder/warning in every feature where it will not be available.

• Pan with right mouse button
• Zoom with mouse wheel
• Select and drag nodes with left mouse button
• Add or remove nodes from select with shift + left mouse
• Delete selected nodes with delete key
• Home key will set view position and zoom so that all nodes are in view
• Hold Ctrl while drag-selecting an area to zoom that area to fit the view
• Undo/redo with Ctrl+Z and Ctrl+Shift+Z (Cmd instead of Ctrl on Mac)

Pin	GPIO	5V ok?
1	A10	ok	UART1 RX
2	A9	ok	UART1 TX
3	A15	ok
4	C10	ok	UART2 TX
5	C11	ok	UART2 RX
6	C12	ok
7	D2	ok	Red LED
8	B3	ok
9	B4	ok	PWM in
10	B5	ng	PWM in	RGB LED strip
11	B6	ok	PWM in
12	B7	ok	PWM in
13	B8	ok	PWM in
14	B9	ok	PWM in
15	C13	ng
16	C14	ng	Rotary encoder CLK
17	C15	ng	Rotary encoder DT
18	C0	ng	Analog in
19	C1	ng	Analog in
20	C2	ng	Analog in
21	C3	ng	Analog in
22	C5	ng	Analog in
23	C4	ng	Analog in
24	A0	ng
25	A1	ng
26	A2	ng	UART3 TX
27	A3	ng	UART3 RX
28	A4	ng
29	A5	ng
30	A6	ng
31	A7	ng
32	B0	ng
33	B1	ng
34	B11	ok	I2C SDA
35	B10	ok	I2C SCL
36	C6	ok	Duty cycle PWM
37	C7	ok	Duty cycle PWM
38	C8	ok	Duty cycle PWM
39	C9	ok	Duty cycle PWM
40	A8	ok	Blue LED