iagent - User contributions [en]

Voron 0.1

2026-10-14T16:53:28Z

Elias:

Using Recore A8 and Retool A2 in a Voron 0.1. This page is a work in progress.

See also [[Voron 2.4]] for the same boards in a larger Voron.

==Hardware==
* [[Recore A8]] as the main board
* [[Retool A2]] as the USB toolhead board (extruder, hotend heater and thermistor, fans, accelerometer, Neopixel)
== Rewire diagram==
[[https://rewire.iagent.no/#cfg=zH4sIAAAAAAAAA4VVy06kQBTd-xWVuK1k6l0FO51p42QSNWLrkjDd1UqCQADH1sV8-1yqeE5DXDQNt86599wXnP9FlX1PK4sui6Tax_d2V1Q2vjDoLd0jipIGBZJiZSSqigaRs_MTQlMUWXzBHIG1BGoUx5obz4BrZpE9NtXb3lYL_Nrm-57PHV9ohrUMViP-KbKmZwgnEQJSwsgJI2psWdrKIaVHakypDqbaag-KjxPiBjTVTVE6pvJZEYmNFo7J9FoU7bBEkzaMXgrzsRbGeCqjWOrTVK6SPL7MinfwIMjrq2MEjqGZxoFQjgEqfbQyqZr_2AONur7SwMiB17FeiqbtxiHJV9KjfYcpDpj6osM3xednZuMfVfJc5Ifsw3vwPdZUYtWnue7BFmV6tFlcp_kzQJwD6dVLhZXoK3zI0hLRtcrSriswJlKzaczjSp4wSy2DawGDJclSHz_5F0KZnxvKBJYL-xPZXZMWefwrze1r0qS72rO8VqYYFuqUdRdtPcxNC-McUGRhJr9THh_eaq-Eu5obcEmZOXHJGHmM6_e02b14tNsppSWg9Qn62iaN3ce_4cfEoyf4jsAYmpkUh-fhNrqMb7cPBDF3-_NmPBRhpJAMo9Giwk3UIjcRnaI00lMUC68oCsKrmYVBrecm8ETZnHcNJg7XwQRPTtrDFHWzufWSqXT3U800jBjMx9QtBbnsW0ei0PgFkkv9VnT1mJ7x8O7pHiQY9z-aRbil0Dq4zmzE2aauF-nGFbJVJkeoHoxi9CldUcJrPjW1uYcPfBaZtUG2c4Xc2SYKeY9jzlYuDgCiigssYFxoQBXWRnTgsUEAgXmFz0h3MpYdPhCwUoExQ4BpAYAtAqxhgZXkGN4SPWosJ9IMvhc8mJx0RUWawIub6P5kKA0ysGmG8PGgKxASBlaQDwdj-m6DmNBn_wDn8m0-ZAcAAA]]

==Software==
The printer runs [[Rebuild]] with Fluidd. The Retool A2 runs Klipper's stock RP2040 firmware, which Rebuild installs and keeps in step with the host.

==Klipper configuration==
The Recore A8 uses the reference config that comes with Rebuild (<code>rebuild-reference/generic-recore-a8.cfg</code>), with the Fluidd config and the toolhead config included from <code>printer.cfg</code>:

<pre>
[include fluidd.cfg]
[include Retool_A2.cfg]
</pre>

The Retool A2 is a separate Klipper MCU, found by its serial number:

<pre>
ls /dev/serial/by-id/
</pre>

Put the path that shows up for the Retool in <code>[mcu retool]</code>. The toolhead config is based on the one used in the [[Voron 2.4]]. Its extruder is called <code>extruder3</code> and its fans have their own names, so it can be included next to the A8 config. The heater, thermistor and PID values still have to be set for the hotend that is fitted, and PID tuned.

==To do==
* Wire diagram and layout
* Toolhead mount and 3D model
* Tested configuration and settings

Recore A8

2026-10-09T12:09:13Z

Elias: OFFSET-T2 is PG2 (GPIO 194), not PG3: PG3 is UC-INT-1 (checked against the schematics' netlists)

<div class="res-img">
[[File:Recore header.png]]
</div>
Recore is a 3D-printer control board running Linux. It is specifically tailored to be compatible with Klipper and OctoPrint, MainSail or Fluidd. The main features are:
* Allwinner A64 SoC, quad core CPU running at 1 GHz.
* 1 GB of DDR3 RAM
* 8 GB of on board eMMC
* Gigabit Ethernet
* 6 TMC2209, 2 A stepper motor drivers
* 3 heater outputs + high power heated bed
* 4 USB High Speed ports
* 4 thermistor/thermocouple inputs (software selectable)
* Comes with Debian Linux with Klipper and OctoPrint, MainSail or Fluidd installed

This document is for Recore Revision A8. For previous hardware revisions, please see:
* [[Recore_A7]]
* [[Recore_A6]]
* [[Recore_A5]]
* [[Recore_A4]]
* [[Recore_A3]]
* [[Recore_A2]]

==Availability==
Recore A8 can be purchased from the Intelligent Agent web shop [https://www.iagent.no/product/recore/ https://www.iagent.no/product/recore/]

==Schematics==
Recore is "open schematic", it is available here: [https://github.com/intelligent-agent/Recore/blob/master/Schematics/Recore_A8.pdf https://github.com/intelligent-agent/Recore/blob/master/Schematics/Recore_A8.pdf]

==3D model==
A STEP file of the PCB with components is available here: [https://github.com/intelligent-agent/Recore/blob/master/3D-files/Recore_A8.step https://github.com/intelligent-agent/Recore/blob/master/3D-files/Recore_A8.step]
==CE and FCC==
Recore has been certified according to 2014/30/EU. The certificate of compliance can be downloaded here: [http://feeds.iagent.no/doc/CE-Recore.pdf CE-Recore.pdf]<br>
The FCC declaration of conformity can be downloaded here: [http://feeds.iagent.no/doc/FCC-Recore.pdf FCC-Recore.pdf]

=Pinout=
<div class="res-img">
[[File:Recore A8 pinout.png]]
</div>

==A64==
The Allwinner A64 is a quad core Cortex A53 clocked at 1 GHz. It has an integrated RISC CPU (AR100) clocked at 300 MHz that handles the real time aspect for the 3D-printer. In the following table the pins used for End-stops and stepper control are described.
The "bank and pin" can be used to specify the pin numbers in klipper.
The "Number" column is useful for testing things on the command line in conjunction with gpiod.

{| class="wikitable" style="width: 100%;
! Name !! Bank and pin !!style="border-right:solid 2px;"| Number !! Name !! Bank and pin !!style="border-right:solid 2px;"| Number !! Name !! Bank and pin !! Number
|-
| STEP 0 || PL4 ||style="border-right:solid 2px;"| 4 || END STOP 0 || PH4 ||style="border-right:solid 2px;"|228 || OC-ALERT || PF6 || 166
|-
| STEP 1 || PL5 ||style="border-right:solid 2px;"| 5 || END STOP 1 || PH5 ||style="border-right:solid 2px;"| 229 || OC-RESET || PF4 || 164
|-
| STEP 2 || PL6 ||style="border-right:solid 2px;"| 6 || END STOP 2 || PH6 ||style="border-right:solid 2px;"| 230 || EN-HP || PF5 || 165
|-
| STEP 3 || PL7 ||style="border-right:solid 2px;"| 7 || END STOP 3 || PH7 ||style="border-right:solid 2px;"| 231 || UC-INT-1 || PG3 || 195
|-
| STEP 4 || PL8 ||style="border-right:solid 2px;"| 8 || END STOP 4 || PH8 ||style="border-right:solid 2px;"| 232 || UC-NRST || PG4 || 196
|-
| STEP 5 || PL9 ||style="border-right:solid 2px;"| 9 || END STOP 5 || PH9 ||style="border-right:solid 2px;"| 233 || UC-BOOT || PG5 || 197
|-
| STEP 6 || PL10 ||style="border-right:solid 2px;"| 10 || GAIN-ENABLE-T0 || PD4 ||style="border-right:solid 2px;"| 100 || ES-EN-12V || PF0 || 160
|-
| STEP 7 || PL11 ||style="border-right:solid 2px;"| 11 || GAIN-ENABLE-T1 || PH11 ||style="border-right:solid 2px;"| 235 || EN-THERMISTORS || PF1 || 161
|-
| DIR 0 || PE8 ||style="border-right:solid 2px;"| 136 || GAIN ENABLE T2 || PE17 ||style="border-right:solid 2px;"| 145 || EN-ENDSTOPS || PF2 || 162
|-
| DIR 1 || PE9 ||style="border-right:solid 2px;"| 137 || GAIN ENABLE T3 || PB2 ||style="border-right:solid 2px;"| 34 || USR-BTN || PB3 || 35
|-
| DIR 2 || PE10 ||style="border-right:solid 2px;"| 138 || PU-ENABLE-T0 || PG10 ||style="border-right:solid 2px;"| 202 || USR-PIN || PF3 || 163
|-
| DIR 3 || PE11 ||style="border-right:solid 2px;"| 139 || PU-ENABLE-T1 || PG11 ||style="border-right:solid 2px;"| 203 || SBU1 || PC0 || 64
|-
| DIR 4 || PE12 ||style="border-right:solid 2px;"| 140 || PU ENABLE T2 || PG12 ||style="border-right:solid 2px;"| 204 || SBU2 || PC2 || 66
|-
| DIR 5 || PE13 ||style="border-right:solid 2px;"| 141 || PU ENABLE T3 || PG13 ||style="border-right:solid 2px;"| 205 || || ||
|-
| DIR 6 || PE14 ||style="border-right:solid 2px;"| 142 || OFFSET-T0 || PG0 ||style="border-right:solid 2px;"| 192 || || ||
|-
| DIR 7 || PE15 ||style="border-right:solid 2px;"| 143 || OFFSET-T1 || PG1 ||style="border-right:solid 2px;"| 193 || || ||
|-
| STEP DIAG 0 || PE0 ||style="border-right:solid 2px;"| 128 || OFFSET-T2 || PG2 ||style="border-right:solid 2px;"| 194 || || ||
|-
| STEP DIAG 1 || PE1 ||style="border-right:solid 2px;"| 129 || OFFSET-T3 || PG8 ||style="border-right:solid 2px;"| 200 || || ||
|-
| STEP DIAG 2 || PE2 ||style="border-right:solid 2px;"| 130 || STEPPER UART 0-3 || PE16 ||style="border-right:solid 2px;"| 144 || || ||
|-
| STEP DIAG 3 || PE3 ||style="border-right:solid 2px;"| 131 || STEPPER UART 4-5 || PD24 ||style="border-right:solid 2px;"| 120 || || ||
|-
| STEP DIAG 4 || PE4 ||style="border-right:solid 2px;"| 132 || STEPPER UART 6 || PD2 ||style="border-right:solid 2px;"| 98 || || ||
|-
| STEP DIAG 5 || PE5 ||style="border-right:solid 2px;"| 133 || STEPPER UART 7 || PD3 ||style="border-right:solid 2px;"| 99 || || ||
|-
| STEP DIAG 6 || PD0 ||style="border-right:solid 2px;"| 96 || STEPPERS ENABLE || PL12 ||style="border-right:solid 2px;"| || || ||
|-
| STEP DIAG 7 || PD1 ||style="border-right:solid 2px;"| 97 || || ||style="border-right:solid 2px;"| || || ||
|}

==STM32F031==
The STM32 is a Cortex M0 powered micro controller handling analog inputs and PWM outputs. It does not control any hard real time aspects of the print, that is handled by the AR100 core realized as a separate core in the A64 SoC.

{| class="wikitable" style="width: 100%;
! Name !! Bank and pin !!style="border-right:solid 2px;"| Number !! Name !! Bank and pin !!style="border-right:solid 2px;"| Number !! Name !! Bank and pin !! Number
|-
| HEATER E0 || PA8 ||style="border-right:solid 2px;"| 18 || THERMISTOR 0 || PA0 ||style="border-right:solid 2px;"| 6 || ES1-DIR || PB3 || 26
|-
| HEATER E1 || PA9 ||style="border-right:solid 2px;"| 19 || THERMISTOR 1 || PA1 ||style="border-right:solid 2px;"| 7 || ES2-DIR || PB6 || 29
|-
| HEATER E2 || PA10 ||style="border-right:solid 2px;"| 20 || THERMISTOR 2 || PA2 ||style="border-right:solid 2px;"| 8 || EXT 1 || PB7 || 30
|-
| HEATER BED || PA11 ||style="border-right:solid 2px;"| 21 || THERMISTOR 3 || PA3 ||style="border-right:solid 2px;"| 9 || EXT 2 || PB8 || 32
|-
| FAN 0 || PF0 ||style="border-right:solid 2px;"| 2 || BOARD VOLTAGE || PA4 ||style="border-right:solid 2px;"| 10 || EXT 3 || PA13 || 23
|-
| FAN 1 || PB1 ||style="border-right:solid 2px;"| 15 || BOARD CURRENT || PA5 ||style="border-right:solid 2px;"| 11 || EXT 4 || PB2 || 16
|-
| FAN 3 || PB4 ||style="border-right:solid 2px;"| 27 || BOARD TEMPERATURE || PA6 ||style="border-right:solid 2px;"| 12 || USER LED || PA12 || 22
|-
| FAN 2 || PB5 ||style="border-right:solid 2px;"| 28 || COLD JUNCTION || PA7 ||style="border-right:solid 2px;"| 13 || FAN_CURRENT || PB0 || 14
|}

==DBG header==
The debug header has UART 0 layed out on some of the pins and is used for interacting with u-boot and getting early debug messages from the Linux kernel. It also has a the option to connect a "boot" button so the board can be safely started and shut down from the 3D-printers front panel. The USR pin can be used to light up a an LED or some other custom function.
{| class="wikitable"
!Pin
!Function
|-
|1
|UART RX
|-
|2
|UART TX
|-
|3
|3.3V
|-
|4
|GND
|-
|5
|BOOT
|-
|6
|USR
|-
|}

==MCU header==
The MCU header is used for connecting external peripherals to the STM32F031 micro controller on the board. There are 4 pins in total available to use. In addition, there is a ground pin and a 3.3 V pin available.
{| class="wikitable"
!Pin
!Function
!Alt
|-
|1
|PB7
|I2C1_SDA
|-
|2
|PB8
|I2C1_SCL
|-
|3
|3.3V
|0.7-3.3V
|-
|4
|GND
|-
|5
|PA13
|EXTI 13
|-
|6
|PB2
|EXTI 2
|-
|}

==SPI on S6 and S7 headers==
{| class="wikitable"
!Pin
!Function
!Alt
|-
|S6-3
|PD0
|SPI1_CS
|-
|S6-5
|PD1
|SPI1_CLK
|-
|S7-3
|PD2
|SPI1_MOSI
|-
|S7-5
|PD3
|SPI1_MISO
|-
|}

===LEDs===
There are 15 white LEDs on the board. Here is what they mean
{| class="wikitable"
!Name
!Location
!Meaning
|-
|D2
|By PMIC
|Board powered
|-
|D3
|By heater BED
|BED output on
|-
|D4
|By fan 0
|Fan 0 is on
|-
|D5
|By fan 1
|Fan 1 is on
|-
|D6
|By heater H2
|Heater H2 is on
|-
|D7
|By fan 2
|Fan 2 is on
|-
|D8
|By heater H0
|Heater H0 is on
|-
|D9
|By fan 3
|Fan 3 is on
|-
|D10
|By heater H1
|Heater H1 is on
|-
|D12
|By input connector
|High voltage domain is on
|-
|D15
|By eMMC chip
|eMMC activity
|-
|D17
|By USB hub chip
|USB activitiy
|-
|D18
|By the USB C connector
|Linux Heartbeat
|-
|D19
|By the A64 SoC
|CPU activity
|-
|D20
|By the STM32
|Klipper running on STM32
|-
|}

===Buttons===
There are 3 push buttons on the board.
{| class="wikitable"
!Name
!Meaning
|-
|FEL
|Enter FEL-mode of the A64
|-
|BOOT
|Boots or shuts down the board
|-
|RESET
|Hard reset of the CPU
|-
|}

==Current limits==
{| class="wikitable"
|-
!Name
!Limit
|-
|5V-ES (endstops)
|0.75 A
|-
|USB host 3 and 4 each (5VP)
|1.1 A
|-
|USB host 1 and 2 each (VSP)
|0.75 A
|-
|Thermistors
|0.75 A
|-
|MCU and DBG connector
|0.5 A
|-
|Fan connectors
|programmable
|-
|Heater connectors
|programmable
|-
|}

=Wiring=
Below is a wiring diagram meant to aid in connecting motors, fans, extruders and hot ends to the control board. On the board, there is a small + sign next to output connectors where polarity is important. If passive heating elements are used, polarity is not important, but if those outputs are to be used with SSRs or relays, polarity must be observed.
<div class="res-img">
[[File:Recore-wire-diagram-3.png]]
</div>

==Network connection==
Recore is designed to be controlled through a browser on a computer, so the board must be connected to the local LAN or wifi network. Connect an ethernet cable between the board and a switch. The ping utility can be used to ensure that the board is discovered on the network.

===LAN setup===
Recore with Refactor is running avahi and should announce itself on the network once a connection has been established. On a Linux based host computer, it is possible to search for a booted device using the following command:
<pre>
ping recore.local
</pre>
If the device is present, an SSH connection can be established:
<pre>
ssh root@recore.local
</pre>
Furthermore, a web interface running OctoPrint can be found using a browser:<br>

http://recore.local

==Wifi setup==
Wifi can be set up by connecting a wifi dongle to one of the USB host ports. Once the uSB dongle has been connected, and the board has been booted, access to the terminal command line can be given through a host computer. The board should appear as a TTY ACM device. On a Linux based host computer, the terminal program `screen` can be used to get access. From the host computer
<pre>
screen /dev/ttyACM0 115200
</pre>

If the host computer is running Windows, [https://www.putty.org/ Putty] can be used to get access.

Once a connection has been established, the wifi network can be set up using the command nmtui.
<pre>
nmtui
</pre>
Follow the instructions on screen to edit and activate the wifi connection.
<div class="alert alert-warning">
===='''Note'''====
If the board is powered through the USB C connector, only the two USB host ports next to the HDMI port is powered.
</div>

==Mating Connectors==
The power connectors on the board are available either in the web shop as part of a [https://www.iagent.no/product/recore-connector-pack-a8/ connector pack] or directly from Digi-key etc.
<div class="res-img">
[[File:Connectors A8.png]]
</div>
Four pin male: TBP01P1-508-04BE [[https://www.digikey.com/en/products/detail/cui-devices/TBP01P1-508-04BE/10238369 | Digi-key]]

Two pin male: TBP01P1-508-02BE [[https://www.digikey.com/en/products/detail/cui-devices/TBP01P1-508-02BE/10238367 | Digi-key]]

Two pin female housing: PHR-2-BK

Three pin female housing: PHR-3-BK

Four pin female housing: PHR-4-BK

=Klipper Configuration=
There are no jumpers on Recore and no hard fuses. Everything is software configurable and resettable from software. This gives great power and flexibility without requiring physical access to the board once it has been installed. But with great power comes great responsibility. It is possible to break things if care is not taken during setup. There is one setting in particular that is worth mentioning: ES0 can have either +5V or +12V on the power pin. This is in order to allow a standard industrial inductive sensor to be used on that end stop. If a 5V only peripheral is connected, that could damage the connected peripheral.

The default config file for Recore A8 can be found in the repository: [https://github.com/intelligent-agent/Rebuild/blob/main/userpatches/overlay/klipper/generic-recore-a8.cfg generic-recore-a8.cfg]

===TMC2209===
The 6 stepper drivers on Recore are of type TMC2209 from Trinamic. Each stepper has a configuration interface with a bidirectional UART port that is connected to a pin on the A64. The GPIO bit-banging functionality of Klipper is used to communicate with the stepper drivers.

Here is a table with pins and addresses for the steppers
{| class="wikitable"
!colspan="3"|Stepper driver config
|-
|Name
|Pins
|Address
|-
|S0
|PE16
|0
|-
|S1
|PE16
|1
|-
|S2
|PE16
|2
|-
|S3
|PE16
|3
|-
|S4
|PD24
|0
|-
|S5
|PD24
|1
|-
|S6
|PD2
|0-3
|-
|S7
|PD3
|0-3
|-
|}

=== External stepper drivers ===
<div class="res-img">
[[File:Ext-driver.png]]
</div>
It is possible to connect up to two external stepper drivers to Recore in addition to the 6 divers installed on the board.
These can be connected using the headers S6 and S7.

See also [[Restep_A1]] for a convenient alternative external stepper driver.

==Temperature inputs==
4 different temperature devices can be connected to the 4 analog inputs on Recore. Thermistor, Thermocouple, PT100 with INA826 and PT1000 without the use of a pre-amplifier.
===Thermistor===
<div class="res-img">
[[File:Thermistor.png]]
</div>
Make sure the pull-up is enabled and the op-amp gain is set to 1.

===Thermocouple===
<div class="res-img">
[[File:Thermocouple.png]]
</div>

Make sure the pull-up is disabled and the op-amp gain is set to 100.
<pre>
[recore]
...
gain_t0: 100
pullup_t0: 0
offset_t0: 1

[Extruder]
...
sensor_type: Type K
</pre>

===PT100 with INA826===
<div class="res-img">
[[File:PT100.png]]
</div>

In order to use a PT100 sensor, an external amplifier board must be used. There is an example configuration for Klipper that
uses this. The ADC reference voltage is 5.0 by default, but for Recore it is 3.3 V. Here is an example:
<pre>
[Extruder]
...
sensor_type: PT100 INA826
adc_voltage: 3.27
</pre>

The pull-up must also be disabled.

===PT1000===
<div class="res-img">
[[File:PT1000.png]]
</div>
Make sure the pull-up is enabled and the gain is set to 1. In the latest version, the sensor must be prefixed with RECORE.
<pre>
[Extruder]
...
sensor_type: PT1000
pullup_resistor: 4750
</pre>

===End stops===
There are 6 end stop inputs on Recore, some of them server a dual purpose.

=Connecting other sensors=
The board has been designed to work with a range of 3rd party sensors for automating the print.
==BLtouch==
There are two versions of the BLtouch, the difference is the color of one of the GND wires.
<div class="res-img">
[[File:Antclabs BLtouch sensor wiring.png]]
</div>
The Creality version has a blue GND wire.
<div class="res-img">
[[File:Creality BLtouch sensor wiring.png]]
</div>
<div class="alert alert-warning">
===='''Note'''====
There have been some cases of bad quality control for the Creality BLTouches, where the pinout on the sensor side have not matched the color coding in the photos/documentation. It might be good to make sure the color codes match up. For the Creality it should be, from left to right:
Blue, red, yellow, black, white.
</div>

When connected per wiring diagram above, setting up BLtouch can be done by adding the following section to printer.cfg.
<pre>
[bltouch]
sensor_pin: ar100:PH6
control_pin: !PB3
speed:15
samples:1
pin_move_time: 0.675
sample_retract_dist: 10
probe_with_touch_mode: true
stow_on_each_sample: false
x_offset:29.2
y_offset:-34
z_offset:0
</pre>

==Inductive Sensor ==
<div class="res-img">
[[File:Inductive sensor wiring 2.png]]
</div>
Connect the inductive sensor on ES0. You can choose either 5V or 12V output on the voltage pin. Inductive sensors often come with an industry standard voltage input of 6-36 V. For this reason there is a 12 V LDO (Low drop-out) voltage regulator integrated on the board. This voltage regulator can be output on the V+ pin of the connector marked ES0. If the Input to the board is 12 V, the LDO will supply a lower voltage, around 10.6 or so.

<div class="alert alert-warning">
===='''Note'''====
All the end-stops have a permanent 10 K pull-up resistor between the signal pin (pin 2) and the +5V/+12V (pin3). This will work with an NPN-type inductive sensor. If you have a PNP-type inductive sensor, you need to add a pull-down resistor of a lower value, for instance 1 K. The pull-down resistor goes between the signal pin (pin 2) and ground (pin 1).
</div>

Here is a minimal probe config
<pre>
[probe]
pin: ar100:PH4
</pre>

==ADXL345==
<div class="alert alert-warning">
===='''Note'''====
The ADXL345 seems to cause Klipper to shut down when trying to calibrate at a high rate. A workaround is to use a [https://www.raspberrypi.com/documentation/microcontrollers/pico-series.html Pi Pico] or similar MCU to communicate with the ADXL345, or to lower the rate. It's been tested working at 400, but not 800 which is the recommended minimum.
</div>
See also [[Remove_A1]], a convenient finished accelerometer.

<div class="res-img">
[[File:Wiring.png]]
</div>
A popular accelerometer sensor for doing input shaping with Klipper is the ADXL345. This can be connected to the connectors S6/S7. There is no hardware SPI interface available, but a software implementation in Klipper exists.
Note: Only experimental support has been tested for this.
https://learn.adafruit.com/adxl345-digital-accelerometer

Config:
<pre>
[adxl345]
cs_pin: ar100:PL11
spi_software_sclk_pin: ar100:PL10
spi_software_mosi_pin: ar100:PE15
spi_software_miso_pin: ar100:PE14
rate: 400

[resonance_tester]
accel_chip: adxl345
probe_points:
100, 100, 20 # an example

</pre>

Using a Raspberry Pi Pico:
<pre>
[adxl345]
cs_pin: pico:gpio17
spi_bus: spi0c
</pre>

== Neopixels ==
<div class="img-res">
[[File:Neopixel wiring.png]]
</div>
Use endstop ES1 (PH5) or ES2 (PH6).

<pre>
[neopixel my_neopixel_1]
pin: ar100:PH5

[neopixel my_neopixel_2]
pin: ar100:PH6

[static_digital_output es1_direction]
pins: !PB3

[static_digital_output es2_direction]
pins: !PB6
</pre>

See also [[Relit_A0]]

==RC Servo==
<div class="img-res">
[[File:RC-servo.png]]
</div>
Endstop 1 and 2 can be used as PWM outputs with 5V levels. Rev A6 is the first board with support for this.
More testing and configuration documentation is needed.

==Filament runout sensor==
<div class="img-res">
[[File:Filament-runout-sensor.png]]
</div>
Any of the 6 end stops can be used for connecting a filament runout sensor

=Software for Recore=
Recore comes with the Linux distro Rebuild (Armbian) pre-installed on the eMMC.
For more instructions about software for Recore, see the Rebuild wiki page:
[[ Rebuild ]]

=== AR100 ===
Please see: [[AR100]]

=== Manual control and testing ===
https://wiki.iagent.no/wiki/Manual_control_and_testing

=Performance=
===Start-up time===
With a maximum clock for MMC2 of 200 MHz, here is the start-up time:
<pre>
root@recore:~# systemd-analyze
Startup finished in 3.011s (kernel) + 12.292s (userspace) = 15.303s
graphical.target reached after 11.934s in userspace
</pre>
===eMMC read and write speed===
eMMC write speed: 65.2 MB/s
<pre>
root@recore:~# dd if=/dev/random of=/dev/mmcblk2 bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 16.0853 s, 65.2 MB/s
</pre>

eMMC read speed: 111 MB/s
<pre>
root@recore:~# dd if=/dev/mmcblk2 of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 9.42715 s, 111 MB/s
</pre>

===USB read and write speed===
Software: Reflash v1.0.1<br>
Disk: WD Elements SE<br>
USB write speed: 31.0 MB/s<br>
USB read speed: 33.0 MB/s<br>
<pre>
root@recore:~# dd if=/dev/zero of=/mnt/usb/random.bin bs=1M count=1000 conv=fsync
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 33.8744 s, 31.0 MB/s
</pre>

<pre>
root@recore:~# dd if=/mnt/usb/random.bin of=/dev/null
2048000+0 records in
2048000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 31.7393 s, 33.0 MB/s
</pre>

==Measured voltages==
The final stages of Recore manufacturing consists of testing, calibration and flashing of firmware.
The calibration stage measures a number of voltages on the board and classifies the input stages gain and offset.

====5V Buck converter ripple and noise ====
The 5V step down/Buck converter is a AOZ2153EQI-30. It can provide 8A and has an input voltage range of 12-28V.

Below is a screenshot of the ripple and noise across the the 5V rail with a normal kernel running and pulling 4 A from the USB and with 6 Neopixels connected.
<div class="res-img">
[[File:A8 5V ripple.png]]
</div>

===Input stage===
When drawing a constant current of 20 A from the bed connector with and without any forced convection. The temperature measured was with the on board thermistor. Using a thermal camera, the temperature displayed matches well with the temperature reported by the camera. The maximum board temperature of 100 degrees C is reached after about 10 minutes with no forced convection.
Ambient temperature in the room: 20.1 degrees C.

<div class="res-img">
[[File:Input stage temperature no fan.png|A7 Input stage temperature no fan]]
</div>

With forced convection (a 92 mm Noctua fan) and a current load of 29 A, the maximum temperature reached after 10 minutes was 87.7 degrees C as measured by the on board thermistor. The thermal camera showed a higher temperature of 98 degrees.
<div class="res-img">
[[File:Input stage temperature with fan crop.png|Input stage temperature with fan]]
</div>

==== Maximum input voltage ====
Using 1.5 m test leads and a 26 V bench top PSU (Agilent U8002A) a board has been tested for over voltage issues. This was a problem with Rev A6. No issues were found during testing.

====Inrush current====
During turn on of the high power stage, there will be an inrush current to charge up the bank of capacitors present on the board.
If no loads are turned on, the inrush current reaches 28 A at peak, depending on PSU and cables. This is important to consider when setting the current limit with device tree. Below is a trace of the current draw of Recore A7 when the input is enabled. The PSU in use was a PeakTech 6160 (30V/30A) benchtop switchmode PSU. The cables used were Pomona B-24-0 and B-24-2, 24" 18 AWG banana plug test leads.

<div class="res-img">
[[File:A8 inrush current.png|center]]
</div>

====Over current protection====
There are 3 different sensors present in the input stage for making sure the 12-24 V domain on the board does not overheat during startup and operation.
# The Fast acting over current protection is to ensure that the high power domain is disabled in the case of a short circuit condition.
# The current limit set in Klipper monitors the continuous current draw. This is now set at 20 A, but can go up to 30 A and still be within the limits of the connectors and input stage mosfets.
# The over temperature protection monitors the temperature in the input stage and cuts the power if the temperature goes over 110 degrees. The board should not be kept at this temperature for a prolonged period, but during heated bed heat-up, it can be elevated compared to the rest of the print.

Below is a plot of what the current on the input looks like if there is an over current condition on the high power domain as that domain is turned on.
<div class="res-img">
[[File:A7 over current input turns on.png|center]]
</div>

Below is a plot of what the current on the input looks like if there is an over current condition after the input has been turned on.
<div class="res-img">
[[File:A7 over current output turns on.png|center]]
</div>

===ADC offset and gain measurements===
To measure the ADC offset error, measure the voltage on the uC input pin and record when the
transition from 0 to 1 occurs. It should occur at 0.5 LSB = 3.3/4096/2 = 0.4028 mV.
Offset: 55.35 mV - 0.4028 mV = 54.95 mV

==Temperature calibration==
A set of experiments have been carried out to calibrate the different sensors using a dry-well calibrator.
The reference probe was a Sensing Devices SDL385 PRT.
The levels of calibration was: room temperature, 50, 100, 150, and 200 degrees C.

===Thermistor===
The thermistor in use was a standard EPCOS 100K B57560G104F. This thermistor has a resistance tolerance of 2 %. The value of the pull-up resistor as measured during calibration was 4740.17501. This value seemed to work well at all levels of calibration, although a little on the high side compared to the reference.

===PT1000===
The PT1000 in use was a Heraeus 31500989 [https://www.heraeus.com/media/media/hne/datasheets/sensor_assemblies_1/Heraeus_W-EYK_Sensor_E.pdf] works well. The tolerance class given in the datasheet is "F 0.10 / Class 1/3 B". There are two different tolerances here: F0.10 and one third of Class B. The accuracy looks good at all temperatures, perhaps a bit on the high side if using the calibrated value for the pull-up. During the testing, 10 ohm was subtracted from the calibrated value.

===PT100===
The PT100 used in the calibration was the E3D PT100 with the INA826 amplifier board. There is no datasheet available for the PT100 sensor and no mention of what tolerance there is on the reference resistors used. Furthermore Klipper expects the reference voltage to be 5V exactly, and there is no way to supply a measured value. Measurements on Recore has shown that the value is often a bit lower due to the PMIC for the 5V output on the "input" ports. 4.979 V has been measured and is likely an expected value.

===Thermocouple===
Using the calibration values directly will give a slight offset to the thermocouple measurements.
The gain and ADC voltage can be used as measured during calibration. It should be in the region of 101 for gain and 3.307 for ADC voltage. As for the offset, that can be increased slightly to compensate for the cold junction temperature difference. For instance, the measured offset for the test board was 0.0032960, but a value of 0.00340 fit the data points well. The measurements were done on T2, so it it possible that the distance from the cold junction caused the offset. The cold junction thermistor is located between T0 and T1.

=FAQ=
====Where can I ask for help?====
:You can join the Discord: https://discord.gg/bCnp9H5SB5
====What comes in the box with the Recore? Specifically, terminal connectors for power, etc?====
:It's only the board, no cables or connectors. There is a bag of connectors available to purchase in the web shop.
====Do I need access to those 4 buttons on the board?====
:It is not necessary to have access to the 4 buttons for normal use.

====What's the maximum current draw for heat bed?====
:This has been tested up to 30 A with good cooling using a fan and a heat sink.

====I have a gadget that I want to connect with SPI. Is that possible?====
:On Recore A8, there is support for an SPI peripheral. The pins are broken out on header S6/S7.

====What exactly is the role of the AR100 device?====
:The AR100 handles the fast real-time aspects, mainly the stepper motors and end stops.

====What voltage fans are supported?====
:The same voltage as the input voltage, either 12 V or 24 V. You can experiment with PWM for running lower voltage fans on 24 V input.
====Where is the board layout file?====
:The Layout file will not be available. It is an "open schematic" board, not open source hardware
====Where are you shipping from?====
:Boards are shipping from Norway. Eventually shipping will be from a warehouse in the US

= Known hardware issues for rev A8=
* ENN for steppers does not have a pull-up resistor, so the steppers are enabled once power is applied. (This can be fixed with a software workaround.)
* Using the boot button to start the board from a shut down state does not always start the board. A workaround is to either shut it off again, press the RST button or remove power and then re-apply power.
* The USB drivers in u-boot seem to have some trouble with certain boards and emit the error message
<pre>
EHCI timed out on TD - token=0xXXXXXXXX
</pre>
* Applying the VIN voltage after the board has been booted via USB can cause an instant shutdown.

==List of changes from A7 to A8==
* Use JST 2 mm connectors.
* Add enable pin on stepper motors
* 8 layer PCB
* Higher current 5V step down (AOZ2153EQI-30 8A)
* Reduce clearance from 0.15 to 0.1 on ground layers
* Recalculated transmission line impedances for lower Radiated emission
* Add more decoupling capacitors on CPUX node
* Add USB-button
* USB1 and USB2 can now draw much more current
* Add Mipi VCC
* Terminating resistor for CK on DDR3
* Move AXP803 to make room for larger HDMI trace distances.
* Faster level shifter for using Neopixels.
* Fatter VREF traces on DDR3
* Fix FUSB pin usage.
* Less inrush current
* Lower minimum current limit to 17.5 A (max: 82.5)
* SBU pins connected on USB-C connector

= Migrating Klipper config from A7 to A8 =

{| class="wikitable"
!colspan="3"|[tmc2209 stepper_x]
|-
|Before
|After
|-
|

|enable_pin: !ar100:PL12
|-
|}

Recore A7

2026-10-09T12:09:13Z

Elias: OFFSET-T2 is PG2 (GPIO 194), not PG3: PG3 is UC-INT-1 (checked against the schematics' netlists)

<div class="res-img">
[[File:Recore header.png]]
</div>
Recore is a 3D-printer control board running Linux. It is specifically tailored to be compatible with Klipper and OctoPrint. The main features are:
* Allwinner A64 SoC, quad core CPU running at 1 GHz.
* 1 GB of DDR3 RAM
* 8 GB of on board eMMC
* Gigabit Ethernet
* 6 TMC2209, 2 A stepper motor drivers
* 3 heater outputs + high power heated bed
* 4 USB High Speed ports
* 4 thermistor/thermocouple inputs (software selectable)
* Comes with Debian Linux with Klipper and OctoPrint or MainSail installed

This document is for Recore Revision A7. For previous hardware revisions, please see:
* [[Recore_A6]]
* [[Recore_A5]]
* [[Recore_A4]]
* [[Recore_A3]]
* [[Recore_A2]]

==Availability==
Recore A7 can be purchased from the iagent web shop [https://www.iagent.no/product/recore/ https://www.iagent.no/product/recore/]

Or at Fabreeko [https://www.fabreeko.com/products/recore-a7-by-iagent https://www.fabreeko.com/products/recore-a7-by-iagent]

==Schematics==
Recore is "open schematic", it is available here: [https://github.com/intelligent-agent/Recore/blob/master/Schematics/Recore_A7.pdf https://github.com/intelligent-agent/Recore/blob/master/Schematics/Recore_A7.pdf]
==3D model==
A STEP file of the PCB with components is available here: [https://github.com/intelligent-agent/Recore/blob/master/3D-files/Recore_A7.step https://github.com/intelligent-agent/Recore/blob/master/3D-files/Recore_A7.step]

=Pinout=
<div class="res-img">
[[File:Recore A7 pinout.png]]
</div>

==A64==
The Allwinner A64 is a quad core Cortex A53 clocked at 1 GHz. It has an integrated RISC CPU (AR100) clocked at 300 MHz that handles the real time aspect for the 3D-printer. In the following table the pins used for End-stops and stepper control are described.
The "bank and pin" can be used to specify the pin numbers in klipper.
The "Number" column is useful for testing things on the command line in conjunction with gpiod.

{| class="wikitable" style="width: 100%;
! Name !! Bank and pin !!style="border-right:solid 2px;"| Number !! Name !! Bank and pin !!style="border-right:solid 2px;"| Number !! Name !! Bank and pin !! Number
|-
| STEP 0 || PL4 ||style="border-right:solid 2px;"| 4 || END STOP 0 || PH4 ||style="border-right:solid 2px;"|228 || OC-ALERT || PF6 || 166
|-
| STEP 1 || PL5 ||style="border-right:solid 2px;"| 5 || END STOP 1 || PH5 ||style="border-right:solid 2px;"| 229 || OC-RESET || PF4 || 164
|-
| STEP 2 || PL6 ||style="border-right:solid 2px;"| 6 || END STOP 2 || PH6 ||style="border-right:solid 2px;"| 230 || EN-HP || PF5 || 165
|-
| STEP 3 || PL7 ||style="border-right:solid 2px;"| 7 || END STOP 3 || PH7 ||style="border-right:solid 2px;"| 231 || UC-INT-1 || PG3 || 195
|-
| STEP 4 || PL8 ||style="border-right:solid 2px;"| 8 || END STOP 4 || PH8 ||style="border-right:solid 2px;"| 232 || UC-NRST || PG4 || 196
|-
| STEP 5 || PL9 ||style="border-right:solid 2px;"| 9 || END STOP 5 || PH9 ||style="border-right:solid 2px;"| 233 || UC-BOOT || PG5 || 197
|-
| STEP 6 || PL10 ||style="border-right:solid 2px;"| 10 || GAIN-ENABLE-T0 || PD4 ||style="border-right:solid 2px;"| 100 || ES-EN-12V || PF0 || 160
|-
| STEP 7 || PL11 ||style="border-right:solid 2px;"| 11 || GAIN-ENABLE-T1 || PH11 ||style="border-right:solid 2px;"| 235 || EN-THERMISTORS || PF1 || 161
|-
| DIR 0 || PE8 ||style="border-right:solid 2px;"| 136 || GAIN ENABLE T2 || PE17 ||style="border-right:solid 2px;"| 145 || EN-ENDSTOPS || PF2 || 162
|-
| DIR 1 || PE9 ||style="border-right:solid 2px;"| 137 || GAIN ENABLE T3 || PB2 ||style="border-right:solid 2px;"| 34 || USR || PF3 || 163
|-
| DIR 2 || PE10 ||style="border-right:solid 2px;"| 138 || PU-ENABLE-T0 || PG10 ||style="border-right:solid 2px;"| 202 || || ||
|-
| DIR 3 || PE11 ||style="border-right:solid 2px;"| 139 || PU-ENABLE-T1 || PG11 ||style="border-right:solid 2px;"| 203 || || ||
|-
| DIR 4 || PE12 ||style="border-right:solid 2px;"| 140 || PU ENABLE T2 || PG12 ||style="border-right:solid 2px;"| 204 || || ||
|-
| DIR 5 || PE13 ||style="border-right:solid 2px;"| 141 || PU ENABLE T3 || PG13 ||style="border-right:solid 2px;"| 205 || || ||
|-
| DIR 6 || PE14 ||style="border-right:solid 2px;"| 142 || OFFSET-T0 || PG0 ||style="border-right:solid 2px;"| 192 || || ||
|-
| DIR 7 || PE15 ||style="border-right:solid 2px;"| 143 || OFFSET-T1 || PG1 ||style="border-right:solid 2px;"| 193 || || ||
|-
| STEP DIAG 0 || PE0 ||style="border-right:solid 2px;"| 128 || OFFSET-T2 || PG2 ||style="border-right:solid 2px;"| 194 || || ||
|-
| STEP DIAG 1 || PE1 ||style="border-right:solid 2px;"| 129 || OFFSET-T3 || PG8 ||style="border-right:solid 2px;"| 200 || || ||
|-
| STEP DIAG 2 || PE2 ||style="border-right:solid 2px;"| 130 || STEPPER UART 0-3 || PE16 ||style="border-right:solid 2px;"| 144 || || ||
|-
| STEP DIAG 3 || PE3 ||style="border-right:solid 2px;"| 131 || STEPPER UART 4-5 || PD24 ||style="border-right:solid 2px;"| 120 || || ||
|-
| STEP DIAG 4 || PE4 ||style="border-right:solid 2px;"| 132 || STEPPER UART 6 || PD2 ||style="border-right:solid 2px;"| 98 || || ||
|-
| STEP DIAG 5 || PE5 ||style="border-right:solid 2px;"| 133 || STEPPER UART 7 || PD3 ||style="border-right:solid 2px;"| 99 || || ||
|-
| STEP DIAG 6 || PD0 ||style="border-right:solid 2px;"| 96 || || ||style="border-right:solid 2px;"| || || ||
|-
| STEP DIAG 7 || PD1 ||style="border-right:solid 2px;"| 97 || || ||style="border-right:solid 2px;"| || || ||
|}

==STM32F031==
The STM32 is a Cortex M0 powered micro controller handling analog inputs and PWM outputs. It does not control any hard real time aspects of the print, that is handled by the AR100 core realized as a separate core in the A64 SoC.

{| class="wikitable" style="width: 100%;
! Name !! Bank and pin !!style="border-right:solid 2px;"| Number !! Name !! Bank and pin !!style="border-right:solid 2px;"| Number !! Name !! Bank and pin !! Number
|-
| HEATER E0 || PA8 ||style="border-right:solid 2px;"| 18 || THERMISTOR 0 || PA0 ||style="border-right:solid 2px;"| 6 || ES1-PWM-OUT || PB3 || 26
|-
| HEATER E1 || PA9 ||style="border-right:solid 2px;"| 19 || THERMISTOR 1 || PA1 ||style="border-right:solid 2px;"| 7 || PWM-ES2-OUT || PB6 || 29
|-
| HEATER E2 || PA10 ||style="border-right:solid 2px;"| 20 || THERMISTOR 2 || PA2 ||style="border-right:solid 2px;"| 8 || EXT 1 || PB7 || 30
|-
| HEATER BED || PA11 ||style="border-right:solid 2px;"| 21 || THERMISTOR 3 || PA3 ||style="border-right:solid 2px;"| 9 || EXT 2 || PB8 || 32
|-
| FAN 0 || PF0 ||style="border-right:solid 2px;"| 2 || BOARD VOLTAGE || PA4 ||style="border-right:solid 2px;"| 10 || EXT 3 || PA13 || 23
|-
| FAN 1 || PB1 ||style="border-right:solid 2px;"| 15 || BOARD CURRENT || PA5 ||style="border-right:solid 2px;"| 11 || EXT 4 || PB2 || 16
|-
| FAN 3 || PB4 ||style="border-right:solid 2px;"| 27 || BOARD TEMPERATURE || PA6 ||style="border-right:solid 2px;"| 12 || USER LED || PA12 || 22
|-
| FAN 2 || PB5 ||style="border-right:solid 2px;"| 28 || COLD JUNCTION || PA7 ||style="border-right:solid 2px;"| 13 || FAN_CURRENT || PB0 || 14
|}

==DBG header==
The debug header has UART 0 layed out on some of the pins and is used for interacting with u-boot and getting early debug messages from the Linux kernel. It also has a the option to connect a "boot" button so the board can be safely started and shut down from the 3D-printers front panel. The USR pin can be used to light up a an LED or some other custom function.
{| class="wikitable"
!Pin
!Function
|-
|1
|UART RX
|-
|2
|UART TX
|-
|3
|3.3V
|-
|4
|GND
|-
|5
|BOOT
|-
|6
|USR
|-
|}

It's possible to wire up a boot button so it is accessible from the outside of the printer. This would be the preferred way to start and stop the board. It works the same way as a boot button on any moderns computer does. Press once to shut down a running board, and press and hold for two seconds in order to boot a board. The button should be wired up between the "NO" and "COM" on the button. The light in the button can be connected between +3.3V and the "USR" on the header.
<div class="res-img">
[[File:DBG header.png]]
</div>

==MCU header==
The MCU header is used for connecting external peripherals to the STM32F031 micro controller on the board. There are 4 pins in total available to use. In addition, there is a ground pin and a 3.3 V pin available.
{| class="wikitable"
!Pin
!Function
!Alt
|-
|1
|PB7
|I2C1_SDA
|-
|2
|PB8
|I2C1_SCL
|-
|3
|3.3V
|0.7-3.3V
|-
|4
|GND
|-
|5
|PA13
|EXTI 13
|-
|6
|PB2
|EXTI 2
|-
|}

==SPI on S6 and S7 headers==
<div class="res-img">
[[File:S6 S7 headers.png]]
</div>

{| class="wikitable"
!Pin
!Function
!Alt
|-
|S6-3
|PD0
|SPI1_CS
|-
|S7-3
|PD1
|SPI1_CLK
|-
|S6-5
|PD2
|SPI1_MOSI
|-
|S7-5
|PD3
|SPI1_MISO
|-
|}

===LEDs===
There are 15 white LEDs on the board. Here is what they mean
{| class="wikitable"
!Name
!Location
!Meaning
|-
|D2
|By PMIC
|Board powered
|-
|D3
|By heater BED
|BED output on
|-
|D4
|By fan 0
|Fan 0 is on
|-
|D5
|By fan 1
|Fan 1 is on
|-
|D6
|By heater H2
|Heater H2 is on
|-
|D7
|By fan 2
|Fan 2 is on
|-
|D8
|By heater H0
|Heater H0 is on
|-
|D9
|By fan 3
|Fan 3 is on
|-
|D10
|By heater H1
|Heater H1 is on
|-
|D12
|By input connector
|High voltage domain is on
|-
|D15
|By eMMC chip
|eMMC activity
|-
|D17
|By USB hub chip
|USB activitiy
|-
|D18
|By the USB C connector
|Linux Heartbeat
|-
|D19
|By the A64 SoC
|CPU activity
|-
|D20
|By the STM32
|Klipper running on STM32
|-
|}

===Buttons===
There are 3 push buttons on the board.
{| class="wikitable"
!Name
!Meaning
|-
|FEL
|Enter FEL-mode of the A64
|-
|BOOT
|Boots or shuts down the board
|-
|RESET
|Hard reset of the CPU
|-
|}

==Current limits==
<div class="alert alert-warning">
===='''Note'''====
The amount of current that can be drawn on the two USB host connectors closest to the HDMI connector is not according to spec. The combined current draw for USB 1 and 2 should not exceed 0.4 A.
</div>
{| class="wikitable"
|-
!Name
!Limit
|-
|5V-ES (endstops)
|0.75 A
|-
|USB host 3 and 4 each (5VP)
|1.1 A
|-
|USB host 1 and 2 each (VSP)
|0.75 A
|-
|Thermistors
|0.75 A
|-
|MCU connector
|0.5 A
|-
|Fan connectors
|programmable
|-
|Heater connectors
|programmable
|-
|}

=Wiring=
Below is a wiring diagram meant to aid in connecting motors, fans, extruders and hot ends to the control board. On the board, there is a small + sign next to output connectors where polarity is important. If passive heating elements are used, polarity is not important, but if those outputs are to be used with SSRs or relays, polarity must be observed.
<div class="res-img">
[[File:Rewire-Recore-A7.png]]
</div>

==Network connection==
Recore is designed to be controlled through a browser on a computer, so the board must be connected to the local LAN or wifi network. Connect an ethernet cable between the board and a switch. The ping utility can be used to ensure that the board is discovered on the network.

===LAN setup===
Recore with Refactor is running avahi and should announce itself on the network once a connection has been established. On a Linux based host computer, it is possible to search for a booted device using the following command:
<pre>
ping recore.local
</pre>
If the device is present, an SSH connection can be established:
<pre>
ssh debian@recore.local
</pre>
Furthermore, a web interface running OctoPrint/Mainsail/Fluidd can be found using a browser:<br>

http://recore.local

For more information on this, look at the Rebuild or Refactor wiki pages.

==Wifi setup==
Wifi can be set up by connecting a wifi dongle to one of the USB host ports. Once the USB dongle has been connected, and the board has been booted, access to the terminal command line can be given through a host computer. The board should appear as a TTY ACM device. On a Linux based host computer, the terminal program `minicom` can be used to get access. From the host computer
<pre>
minicom -o -D /dev/ttyACM0 115200
</pre>

If the host computer is running Windows, [https://www.putty.org/ Putty] can be used to get access.

Once a connection has been established, the wifi network can be set up using the command nmtui.
<pre>
nmtui
</pre>
Follow the instructions on screen to edit and activate the wifi connection.
<div class="alert alert-warning">
===='''Note'''====
If the board is powered through the USB C connector, only the two USB host ports next to the HDMI port is powered.
</div>

==Mating Connectors==
The power connectors on the board are available either in the web shop as part of a [https://www.iagent.no/product/connector-pack/ connector pack] or directly from Digi-key etc.
<div class="res-img">
[[File:Connectors-all.png]]
</div>
Four pin male: TBP01P1-508-04BE [[https://www.digikey.com/en/products/detail/cui-devices/TBP01P1-508-04BE/10238369 | Digi-key]]

Two pin male: TBP01P1-508-02BE [[https://www.digikey.com/en/products/detail/cui-devices/TBP01P1-508-02BE/10238367 | Digi-key]]

=Klipper Configuration=
There are no jumpers on Recore and no hard fuses. Everything is software configurable and resettable from software. This gives great power and flexibility without requiring physical access to the board once it has been installed. But with great power comes great responsibility. It is possible to break things if care is not taken during setup. There is one setting in particular that is worth mentioning: ES0 can have either +5V or +12V on the power pin. This is in order to allow a standard industrial inductive sensor to be used on that end stop. If a 5V only peripheral is connected, that could damage the connected peripheral.

The default config file for Recore A6 can be found in the repository: [https://github.com/intelligent-agent/klipper/blob/master/config/generic-recore-a7.cfg generic-recore-a7.cfg]

===TMC2209===
The 6 stepper drivers on Recore are of type TMC2209 from Trinamic. Each stepper has a configuration interface with a bidirectional UART port that is connected to a pin on the A64. The GPIO bit-banging functionality of Klipper is used to communicate with the stepper drivers.

Here is a table with pins and addresses for the steppers
{| class="wikitable"
!colspan="3"|Stepper driver config
|-
|Name
|Pins
|Address
|-
|S0
|PE16
|0
|-
|S1
|PE16
|1
|-
|S2
|PE16
|2
|-
|S3
|PE16
|3
|-
|S4
|PD24
|0
|-
|S5
|PD24
|1
|-
|S6
|PD2
|0-3
|-
|S7
|PD3
|0-3
|-
|}

=== External stepper drivers ===
<div class="res-img">
[[File:Ext-driver.png]]
</div>
It is possible to connect up to two external stepper drivers to Recore in addition to the 6 divers installed on the board.
These can be connected using the headers S6 and S7.

See also [[Restep_A1]] for a convenient alternative external stepper driver.

==Temperature inputs==
4 different temperature devices can be connected to the 4 analog inputs on Recore. Thermistor, Thermocouple, PT100 with INA826 and PT1000 without the use of a pre-amplifier.
===Thermistor===
<div class="res-img">
[[File:Thermistor.png]]
</div>
Make sure the pull-up is enabled and the op-amp gain is set to 1.

===Thermocouple===
<div class="res-img">
[[File:Thermocouple.png]]
</div>

Make sure the pull-up is disabled and the op-amp gain is set to 100.
<pre>
[recore]
...
gain_t0: 100
pullup_t0: 0
offset_t0: 1

[Extruder]
...
sensor_type: Type K
</pre>

===PT100 with INA826===
<div class="res-img">
[[File:PT100.png]]
</div>

In order to use a PT100 sensor, an external amplifier board must be used. There is an example configuration for Klipper that
uses this. The ADC reference voltage is 5.0 by default, but for Recore it is 3.3 V. Here is an example:
<pre>
[Extruder]
...
sensor_type: PT100 INA826
adc_voltage: 3.27
</pre>

The pull-up must also be disabled.

===PT1000===
<div class="res-img">
[[File:PT1000.png]]
</div>
Make sure the pull-up is enabled and the gain is set to 1. In the latest version, the sensor must be prefixed with RECORE.
<pre>
[Extruder]
...
sensor_type: PT1000
pullup_resistor: 4750
</pre>

=Connecting other sensors=
The board has been designed to work with a range of 3rd party sensors for automating the print.
==BLtouch==
There are two versions of the BLtouch, the difference is the color of one of the GND wires.
<div class="res-img">
[[File:Antclabs BLtouch sensor wiring.png]]
</div>
The Creality version has a blue GND wire.
<div class="res-img">
[[File:Creality BLtouch sensor wiring.png]]
</div>
<div class="alert alert-warning">
===='''Note'''====
There have been some cases of bad quality control for the Creality BLTouches, where the pinout on the sensor side have not matched the color coding in the photos/documentation. It might be good to make sure the color codes match up. For the Creality it should be, from left to right:
Blue, red, yellow, black, white.
</div>

When connected per wiring diagram above, setting up BLtouch can be done by adding the following section to printer.cfg.
<pre>
[bltouch]
sensor_pin: ar100:PH6
control_pin: !PB3
speed:15
samples:1
pin_move_time: 0.675
sample_retract_dist: 10
probe_with_touch_mode: true
stow_on_each_sample: false
x_offset:29.2
y_offset:-34
z_offset:0
</pre>

==Inductive Sensor ==
<div class="res-img">
[[File:Inductive sensor wiring 2.png]]
</div>
Connect the inductive sensor on ES0. You can choose either 5V or 12V output on the voltage pin. Inductive sensors often come with an industry standard voltage input of 6-36 V. For this reason there is a 12 V LDO (Low drop-out) voltage regulator integrated on the board. This voltage regulator can be output on the V+ pin of the connector marked ES0. If the Input to the board is 12 V, the LDO will supply a lower voltage, around 10.6 or so.

==ADXL345==
<div class="alert alert-warning">
===='''Note'''====
The ADXL345 seems to cause Klipper to shut down when trying to calibrate at a high rate. A workaround is to use a Pi Pico or similar MCU to communicate with the ADXL345, or to lower the rate. It's been tested working at 400, but not 800 which is the recommended minimum.
</div>
See also [[Remove_A1]], a convenient finished accelerometer.

<div class="res-img">
[[File:Wiring.png]]
</div>
A popular accelerometer sensor for doing input shaping with Klipper is the ADXL345. This can be connected to the connectors S6/S7. There is no hardware SPI interface available, but a software implementation in Klipper exists.
Note: Only experimental support has been tested for this.
https://learn.adafruit.com/adxl345-digital-accelerometer

Config:
<pre>
[adxl345]
cs_pin: ar100:PL11
spi_software_sclk_pin: ar100:PL10
spi_software_mosi_pin: ar100:PE15
spi_software_miso_pin: ar100:PE14
rate: 400

[resonance_tester]
accel_chip: adxl345
probe_points:
100, 100, 20 # an example

</pre>

Using a Raspberry Pi Pico:
<pre>
[adxl345]
cs_pin: pico:gpio17
spi_bus: spi0c
</pre>
==MCP2515==
It's possible to connect a CAN controller like the MCP2515 to Recore.
It's important to keep in mind that the GPIO/SPI pins are 3.3V and not 5V tolerant, so the MCP2515 chip must be run from a 3.3V source, while the TIA1050 chip must be powered with 5V. All headers have pin 1 marked as a square pad, while the others are round.
{| class="wikitable"
!MCP2515
!Recore
|-
|5V
|ES1-3
|-
|3.3V
|MCU-3
|-
|GND
|MCU-4
|-
|INT
|S6-1
|-
|SPI1_CS
|S6-3
|-
|SPI1_CLK
|S6-5
|-
|SPI1_MOSI
|S7-3
|-
|SPI1_MISO
|S7-5
|-
|}

== Neopixels ==
<div class="res-img">
[[File:Neopixels wiring A7.png]]
</div>

Use endstop ES1 (PB3) or ES2 (PB6).

<div class="alert alert-warning">
===='''Note'''====
Make sure to use a 100 ohm pull-up from pin S (pin 2) to pin 5V (pin 3)
</div>

<pre>
[neopixel my_neopixel]
pin: PB3
</pre>

See also [[Relit_A0]]

==RC Servo==
<div class="img-res">
[[File:RC-servo.png]]
</div>
Endstop 1 and 2 can be used as PWM outputs with 5V levels. Rev A6 is the first board with support for this.
More testing and configuration documentation is needed.

==Filament runout sensor==
<div class="img-res">
[[File:Filament-runout-sensor.png]]
</div>
Any of the 6 end stops can be used for connecting a filament runout sensor

=== Enable host mode on the USB-C connector ===
<pre>
sudo mount -o remount,rw /boot
sudo armbian-add-overlay /boot/overlay-user/sun50i-a64-usb-host.dts
sudo mount -o remount,ro /boot
</pre>

=Software for Recore=
Recore comes with the Linux distro Refactor (Armbian) pre-installed on the eMMC.
For more instructions about software for Recore, see the Refactor wiki page:
[[ Refactor ]]

=== AR100 ===
Please see: [[AR100]]

=== Manual control and testing ===
https://wiki.iagent.no/wiki/Manual_control_and_testing

=Performance=
===Start-up time===
With a maximum clock for MMC2 of 200 MHz, here is the start-up time:
<pre>
root@recore:~# systemd-analyze
Startup finished in 3.011s (kernel) + 12.292s (userspace) = 15.303s
graphical.target reached after 11.934s in userspace
</pre>
===eMMC read and write speed===
eMMC write speed: 28.8 MB/s
<pre>
root@recore:~# dd if=/dev/zero of=/mnt/emmc/1GB.bin bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 36.4307 s, 28.8 MB/s
</pre>

eMMC read speed: 112 MB/s
<pre>
root@recore:~# dd if=/mnt/emmc/1GB.bin of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 9.34956 s, 112 MB/s
</pre>

=== USB read and write speed (Reflash USB drive)===
USB write speed: 7.7 MB/s
<pre>
root@recore:~# dd if=/dev/zero of=/mnt/usb/1GB.bin bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 135.476 s, 7.7 MB/s
</pre>

<pre>
root@recore:~# dd if=/mnt/usb/1GB.bin of=/dev/null bs=1M
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 67.613 s, 15.5 MB/s
</pre>

==Measured voltages==
The final stages of Recore manufacturing consists of testing, calibration and flashing of firmware.
The calibration stage measures a number of voltages on the board and classifies the input stages gain and offset.
Instruments used:
* HP 3458A, 8.5 digit multimeter
* HP 3245A, Universal Source

====Microcontroller voltages====
VDDA uC: 3.312 V<br>
VDD uC: 3.312 V

Voltage from the PMIC supplied as bias:<br>
0.706 V <br>

====5V Buck converter ripple and noise ====
The 5V step down/Buck converter is a AOZ2151EQI-30. It can provide 4A and has an input voltage range of 12-28V.
It is hard wired to be in PWM mode. PFM mode results in a loud whine.

Below is a screenshot of the ripple and noise across the the 5V rail with a normal kernel running.
<div class="res-img">
[[File:5V ripple A7.png]]
</div>

===Input stage===
When drawing a constant current of 20 A from the bed connector with and without any forced convection. The temperature measured was with the on board thermistor. Using a thermal camera, the temperature displayed matches well with the temperature reported by the camera. The maximum board temperature of 100 degrees C is reached after about 10 minutes with no forced convection.
Ambient temperature in the room: 20.1 degrees C.

<div class="res-img">
[[File:Input stage temperature no fan.png|A7 Input stage temperature no fan]]
</div>

With forced convection (a 92 mm Noctua fan) and a current load of 29 A, the maximum temperature reached after 10 minutes was 87.7 degrees C as measured by the on board thermistor. The thermal camera showed a higher temperature of 98 degrees.
<div class="res-img">
[[File:Input stage temperature with fan crop.png|Input stage temperature with fan]]
</div>

==== Maximum input voltage ====
Using 1.5 m test leads and a 26 V bench top PSU (Agilent U8002A) a board has been tested for over voltage issues. This was a problem with Rev A6. No issues were found during testing.

====Inrush current====
During turn on of the high power stage, there will be an inrush current to charge up the bank of capacitors present on the board.
If no loads are turned on, the inrush current reaches 28 A at peak, depending on PSU and cables. This is important to consider when setting the current limit with device tree. Below is a trace of the current draw of Recore A7 when the input is enabled. The PSU in use was a PeakTech 6160 (30V/30A) benchtop switchmode PSU. The cables used were Pomona B-24-0 and B-24-2, 24" 18 AWG banana plug test leads.

<div class="res-img">
[[File:A7_inrush_current.png|center]]
</div>

====Over current protection====
There are 3 different sensors present in the input stage for making sure the 12-24 V domain on the board does not overheat during startup and operation.
# The Fast acting over current protection is to ensure that the high power domain is disabled in the case of a short circuit condition.
# The current limit set in Klipper monitors the continuous current draw. This is now set at 20 A, but can go up to 30 A and still be within the limits of the connectors and input stage mosfets.
# The over temperature protection monitors the temperature in the input stage and cuts the power if the temperature goes over 110 degrees. The board should not be kept at this temperature for a prolonged period, but during heated bed heat-up, it can be elevated compared to the rest of the print.

Below is a plot of what the current on the input looks like if there is an over current condition on the high power domain as that domain is turned on.
<div class="res-img">
[[File:A7 over current input turns on.png|center]]
</div>

Below is a plot of what the current on the input looks like if there is an over current condition after the input has been turned on.
<div class="res-img">
[[File:A7 over current output turns on.png|center]]
</div>

===ADC offset and gain measurements===
To measure the ADC offset error, measure the voltage on the uC input pin and record when the
transition from 0 to 1 occurs. It should occur at 0.5 LSB = 3.3/4096/2 = 0.4028 mV.
Offset: 55.35 mV - 0.4028 mV = 54.95 mV

==Temperature calibration==
A set of experiments have been carried out to calibrate the different sensors using a dry-well calibrator.
The reference probe was a Sensing Devices SDL385 PRT.
The levels of calibration was: room temperature, 50, 100, 150, and 200 degrees C.

===Thermistor===
The thermistor in use was a standard EPCOS 100K B57560G104F. This thermistor has a resistance tolerance of 2 %. The value of the pull-up resistor as measured during calibration was 4740.17501. This value seemed to work well at all levels of calibration, although a little on the high side compared to the reference.

===PT1000===
The PT1000 in use was a Heraeus 31500989 [https://www.heraeus.com/media/media/hne/datasheets/sensor_assemblies_1/Heraeus_W-EYK_Sensor_E.pdf] works well. The tolerance class given in the datasheet is "F 0.10 / Class 1/3 B". There are two different tolerances here: F0.10 and one third of Class B. The accuracy looks good at all temperatures, perhaps a bit on the high side if using the calibrated value for the pull-up. During the testing, 10 ohm was subtracted from the calibrated value.

===PT100===
The PT100 used in the calibration was the E3D PT100 with the INA826 amplifier board. There is no datasheet available for the PT100 sensor and no mention of what tolerance there is on the reference resistors used. Furthermore Klipper expects the reference voltage to be 5V exactly, and there is no way to supply a measured value. Measurements on Recore has shown that the value is often a bit lower due to the PMIC for the 5V output on the "input" ports. 4.979 V has been measured and is likely an expected value.

===Thermocouple===
Using the calibration values directly will give a slight offset to the thermocouple measurements.
The gain and ADC voltage can be used as measured during calibration. It should be in the region of 101 for gain and 3.307 for ADC voltage. As for the offset, that can be increased slightly to compensate for the cold junction temperature difference. For instance, the measured offset for the test board was 0.0032960, but a value of 0.00340 fit the data points well. The measurements were done on T2, so it it possible that the distance from the cold junction caused the offset. The cold junction thermistor is located between T0 and T1.

=FAQ=
====Where can I ask for help?====
:You can join the Discord: https://discord.gg/bCnp9H5SB5
====What comes in the box with the Recore? Specifically, terminal connectors for power, etc?====
:It's only the board, no cables or connectors. There is a bag of connectors available to purchase in the web shop.
====Do I need access to those 3 buttons on the board?====
:It is not necessary to have access to the three buttons for normal use.
====What's the maximum current draw for heat bed?====
:This has been tested up to 30 A with good cooling using a fan and a heat sink.

====I have a gadget that I want to connect with SPI. Is that possible?====
:On Recore A7, there is support for an SPI peripheral. The pins are broken out on header S6/S7.

====What exactly is the role of the AR100 device?====
:The AR100 handles the fast real-time aspects, mainly the stepper motors and end stops.

====What voltage fans are supported?====
:The same voltage as the input voltage, either 12 V or 24 V. You can experiment with PWM for running lower voltage fans on 24 V input.
====Where is the board layout file?====
:The Layout file will not be available. It is an "open schematic" board, not open source hardware
====Where are you shipping from?====
:Boards are shipping from Norway. Eventually shipping will be from a warehouse in the US

= Known hardware issues for rev A7=
=== Neopixels needs a lower value pull-up resistor than the 1K present on the board===

==List of changes to revision A7 from A6==
# Step down AOZ2151EQI-30, lower dissipation.
# Separate fan over current protection.
# Use one of the electrolytic capacitors as input capacitor.
# Add a 10K pull-down on the USB power lines, so the USB over-current is unambiguous.
# Make op-amp more symmetric in order to improve the amplifier issue from A6.
# Add USR pin to the DBG header
# Add BOOT pin to the DBG header
# Move the USB activity LED close to the USB hub.
# Use CY7C65634 USB hub because GL850G-OHY37 is discontinued
# Change MCU and DBG connectors from 4 to 6 pins.
# Add SPI to S6/S7
# Add a guard ring on the edge on all layers.
# Use Kelvin connection on mosfets for Op-amps.
# Mitigate inrush current. Consider C214 = 1 nF from G to GND.
# Make better return paths for eth clock traces.

= Migrating Klipper config from A6 to A7 =

{| class="wikitable"
!colspan="3"|Section [recore]
|-
|Before
|After
|-
|revision: A6
|revision: A7
|-
|}

{| class="wikitable"
!colspan="3"|[tmc2209 stepper_x]
|-
|Before
|After
|-
|uart_pin: ar100:PB1
tx_pin: ar100:PB0
|uart_pin: ar100:PE16
|-
|}

{| class="wikitable"
!colspan="3"|[mcu]
|-
|Before
|After
|-
|serial: /dev/ttyS4
|serial: /dev/ttyS2
|-
|}

{| class="wikitable"
!colspan="3"|[fan]
|-
|Before
|After
|-
|pin: PB0
|pin: PF0
|-
|}

Recore A6

2026-10-09T12:09:12Z

Elias: OFFSET-T2 is PG2 (GPIO 194), not PG3: PG3 is UC-INT-1 (checked against the schematics' netlists)

<div class="res-img">
[[File:Recore header.png]]
</div>
Recore is a 3D-printer control board running Linux. It is specifically tailored to be compatible with Klipper and OctoPrint. The main features are:
* Allwinner A64 SoC, quad core CPU running at 1 GHz.
* 1 GB of DDR3 RAM
* 8 GB of on board eMMC
* Gigabit Ethernet
* 6 TMC2209, 2 A stepper motor drivers
* 3 heater outputs + high power heated bed
* 4 USB High Speed ports
* 4 thermistor/thermocouple inputs (software selectable)
* Comes with Debian Linux with Klipper and OctoPrint installed

This document is for Recore Revision A6. For previous hardware revisions, please see:
* [[Recore_A5]]
* [[Recore_A4]]
* [[Recore_A3]]
* [[Recore_A2]]

==Availability==
Recore A6 can no longer be purchased from the Intelligent Agent web shop [https://www.iagent.no/product/recore/ https://www.iagent.no/product/recore/] - instead you will receive the newer [[Recore_A7]] or later batch as they become available.

== Software release notes ==

Currently, the latest version to use to flash a Recore A6 is tested as [https://github.com/intelligent-agent/Reflash/releases/tag/v0.0.8 Reflash 0.0.8]

The latest recommended versions of Refactor to flash on Recore A6 is [https://github.com/intelligent-agent/Refactor/releases/tag/v3.1.3 ReFactor 3.1.3]

==Schematics==
Recore is "open schematic", it is available here: [https://github.com/intelligent-agent/Recore/tree/master/Schematics https://github.com/intelligent-agent/Recore/tree/master/Schematics]

=Pinout=
<div class="res-img">
[[File:Pinout A6-2.png]]
</div>
==A64==
The Allwinner A64 is a quad core Cortex A53 clocked at 1 GHz. It has an integrated RISC CPU (AR100) clocked at 300 MHz that handles the real time aspect for the 3D-printer. In the following table the pins used for End-stops and stepper control are described.
The "bank and pin" can be used to specify the pin numbers in klipper.
The "Number" column is useful for testing things on the command line in conjunction with gpiod.

{| class="wikitable" style="width: 100%;
!Name
!Bank and pin
!style="border-right:solid 2px;"| Number
!Name
!Bank and pin
!style="border-right:solid 2px;"| Number
!Name
!Bank and pin
!Number
|-
|END STOP 0
|PH4
|style="border-right:solid 2px;"|228
|DIR 6
|PE14
|style="border-right:solid 2px;"|142
|USB-PWR-EN-0
|PH0
|224
|-
|END STOP 1
|PH5
|style="border-right:solid 2px;"|229
|DIR 7
|PE15
|style="border-right:solid 2px;"|143
|USB-PWR-EN-1
|PH1
|225
|-
|END STOP 2
|PH6
|style="border-right:solid 2px;"|230
|STEP DIAG 0
|PE0
|style="border-right:solid 2px;"|128
|USB-PWR-EN-2
|PH2
|226
|-
|END STOP 3
|PH7
|style="border-right:solid 2px;"|231
|STEP DIAG 1
|PE1
|style="border-right:solid 2px;"|129
|USB-PWR-EN-3
|PH3
|227
|-
|END STOP 4
|PH8
|style="border-right:solid 2px;"|232
|STEP DIAG 2
|PE2
|style="border-right:solid 2px;"|130
|GAIN-ENABLE-T0
|PD4
|100
|-
|END STOP 5
|PH9
|style="border-right:solid 2px;"|233
|STEP DIAG 3
|PE3
|style="border-right:solid 2px;"|131
|GAIN-ENABLE-T1
|PH11
|235
|-
|STEP 0
|PL4
|style="border-right:solid 2px;"|4
|STEP DIAG 4
|PE4
|style="border-right:solid 2px;"|132
|GAIN ENABLE T2
|PE17
|145
|-
|STEP 1
|PL5
|style="border-right:solid 2px;"|5
|STEP DIAG 5
|PE5
|style="border-right:solid 2px;"|133
|GAIN ENABLE T3
|PB2
|34
|-
|STEP 2
|PL6
|style="border-right:solid 2px;"|6
|STEP DIAG 6
|PE6
|style="border-right:solid 2px;"|134
|PU-ENABLE-T0
|PG10
|202
|-
|STEP 3
|PL7
|style="border-right:solid 2px;"|7
|STEP DIAG 7
|PE7
|style="border-right:solid 2px;"|135
|PU-ENABLE-T1
|PG11
|203
|-
|STEP 4
|PL8
|style="border-right:solid 2px;"|8
|OC-ALERT
|PF6
|style="border-right:solid 2px;"|166
|PU ENABLE T2
|PG12
|204
|-
|STEP 5
|PL9
|style="border-right:solid 2px;"|9
|OC-RESET
|PF4
|style="border-right:solid 2px;"|164
|PU ENABLE T3
|PG13
|205
|-
|STEP 6
|PL10
|style="border-right:solid 2px;"|10
|EN-HP
|PF5
|style="border-right:solid 2px;"|165
|OFFSET-T0
|PG0
|192
|-
|STEP 7
|PL11
|style="border-right:solid 2px;"|11
|UC-INT-1
|PG3
|style="border-right:solid 2px;"|195
|OFFSET-T1
|PG1
|193
|-
|DIR 0
|PE8
|style="border-right:solid 2px;"|136
|UC-NRST
|PG4
|style="border-right:solid 2px;"|196
|OFFSET-T2
|PG2
|194
|-
|DIR 1
|PE9
|style="border-right:solid 2px;"|137
|UC-BOOT
|PG5
|style="border-right:solid 2px;"|197
|OFFSET-T3
|PG8
|200
|-
|DIR 2
|PE10
|style="border-right:solid 2px;"|138
|ES-EN-12V
|PF0
|style="border-right:solid 2px;"|160
|STEPPER UART 2 TX
|PB0
|32
|-
|DIR 3
|PE11
|style="border-right:solid 2px;"|139
|EN-HDMI-PWR
|PG9
|style="border-right:solid 2px;"|201
|STEPPER UART 2 RX
|PB1
|33
|-
|DIR 4
|PE12
|style="border-right:solid 2px;"|140
|EN-THERMISTORS
|PF1
|style="border-right:solid 2px;"|161
|STEPPER UART 3 TX
|PD0
|96
|-
|DIR 5
|PE13
|style="border-right:solid 2px;"|141
|EN-ENDSTOPS
|PF2
|style="border-right:solid 2px;"|162
|STEPPER UART 3 RX
|PD1
|97
|}

==STM32F031==
The STM32 is a Cortex M0 powered micro controller handling analog inputs and PWM outputs. It does not control any hard real time aspects of the print, that is handled by the AR100 core realized as a separate core in the A64 SoC.
{| class="wikitable" style="width: 100%;
!Name
!Bank and pin
!style="border-right:solid 2px;"| Number
!Name
!Bank and pin
!style="border-right:solid 2px;"| Number
!Name
!Bank and pin
!Number
|-
|THERMISTOR 0
|PA0
|style="border-right:solid 2px;"|6
|HEATER E0
|PA8
|style="border-right:solid 2px;"|18
|FAN 0
|PB0
|14
|-
|THERMISTOR 1
|PA1
|style="border-right:solid 2px;"|7
|HEATER E1
|PA9
|style="border-right:solid 2px;"|19
|FAN 1
|PB1
|15
|-
|THERMISTOR 2
|PA2
|style="border-right:solid 2px;"|8
|HEATER E2
|PA10
|style="border-right:solid 2px;"|20

|ES1-PWM-OUT
|PB3
|26
|-
|THERMISTOR 3
|PA3
|style="border-right:solid 2px;"|9
|HEATER BED
|PA11
|style="border-right:solid 2px;"|21
|FAN 3
|PB4
|27
|-
|BOARD VOLTAGE
|PA4
|style="border-right:solid 2px;"|10
|USER LED
|PA12
|style="border-right:solid 2px;"|22
|FAN 2
|PB5
|28
|-
|BOARD CURRENT
|PA5
|style="border-right:solid 2px;"|11
|
|
|style="border-right:solid 2px;"|
|PWM-ES2-OUT
|PB6
|29
|-
|BOARD TEMPERATURE
|PA6
|style="border-right:solid 2px;"|12
|
|
|style="border-right:solid 2px;"|
|EXT 1
|PB7
|30
|-
|COLD JUNCTION
|PA7
|style="border-right:solid 2px;"|13
|
|
|style="border-right:solid 2px;"|
|EXT 2
|PB8
|32
|}

==DBG header==
This header is used for interacting with u-boot and getting early debug messages from the Linux kernel
{| class="wikitable"
!Pin
!Function
|-
|1
|UART RX
|-
|2
|UART TX
|-
|3
|NC
|-
|4
|GND
|-
|}

==MCU header==
This header is used for connecting additional MCU peripherals.
{| class="wikitable"
!Pin
!Function
!Alt
|-
|1
|PB7
|I2C1_SDA
|-
|2
|PB8
|I2C1_SCL
|-
|3
|3.3V
|0.7-3.3V
|-
|4
|GND
|
|-
|}

===LEDs===
There are 15 white LEDs on the board. Here is what they mean
{| class="wikitable"
!Name
!Location
!Meaning
|-
|D2
|By PMIC
|Board powered
|-
|D3
|By heater BED
|BED output on
|-
|D4
|By fan 0
|Fan 0 is on
|-
|D5
|By fan 1
|Fan 1 is on
|-
|D6
|By heater H2
|Heater H2 is on
|-
|D7
|By fan 2
|Fan 2 is on
|-
|D8
|By heater H0
|Heater H0 is on
|-
|D9
|By fan 3
|Fan 3 is on
|-
|D10
|By heater H1
|Heater H1 is on
|-
|D12
|By input connector
|High voltage domain is on
|-
|D15
|By eMMC chip
|eMMC activity
|-
|D17
|By HDMI connector
|USB activitiy
|-
|D18
|By the USB C connector
|Linux Heartbeat
|-
|D19
|By the A64 SoC
|CPU activity
|-
|D20
|By the STM32
|Klipper running on STM32
|-
|}

===Buttons===
There are 3 push buttons on the board.
{| class="wikitable"
!Name
!Meaning
|-
|FEL
|Enter FEL-mode of the A64
|-
|BOOT
|Boots or shuts down the board
|-
|RESET
|Hard reset of the CPU
|-
|}

==Current limits==
{| class="wikitable"
|-
!Name
!Limit
|-
|5V-ES
|0.75 A
|-
|USB host each
|1.0 A
|-
|Thermistors
|0.75 A
|-
|MCU connector
|0.5 A
|-
|Fan connectors
|programmable
|-
|Heater connectors
|programmable
|-
|}

=Wiring=
Below is a wiring diagram meant to aid in connecting motors, fans, extruders and hot ends to the control board. On the board, there is a small + sign next to output connectors where polarity is important. If passive heating elements are used, polarity is not important, but if those outputs are to be used with SSRs or relays, polarity must be observed.
<div class="res-img">
[[File:Recore-wire-diagram-2.2.png]]
</div>

==Network connection==
Recore is designed to be controlled through a browser on a computer, so the board must be connected to the local LAN or wifi network. Connect an ethernet cable between the board and a switch. The ping utility can be used to ensure that the board is discovered on the network.

===LAN setup===
Recore with Refactor is running avahi and should announce itself on the network once a connection has been established. On a Linux based host computer, it is possible to search for a booted device using the following command:
<pre>
ping recore.local
</pre>
If the device is present, an SSH connection can be established:
<pre>
ssh root@recore.local
</pre>
Furthermore, a web interface running OctoPrint can be found using a browser:<br>

http://recore.local

==Wifi setup==
Wifi can be set up by connecting a wifi dongle to one of the USB host ports. Once the uSB dongle has been connected, and the board has been booted, access to the terminal command line can be given through a host computer. The board should appear as a TTY ACM device. On a Linux based host computer, the terminal program `screen` can be used to get access. From the host computer
<pre>
screen /dev/ttyACM0 115200
</pre>

If the host computer is running Windows, [https://www.putty.org/ Putty] can be used to get access.

Once a connection has been established, the wifi network can be set up using the command nmtui.
<pre>
nmtui
</pre>
Follow the instructions on screen to edit and activate the wifi connection.
<div class="alert alert-warning">
===='''Note'''====
If the board is powered through the USB C connector, only the two USB host ports next to the HDMI port is powered. See also known hardware issues at the [[Recore_A6#USB_connectors_not_discovered_when_powered_by_USB_device|bottom of this page]].
</div>

==Mating Connectors==
The power connectors on the board are available either in the web shop as part of a [https://www.iagent.no/product/connector-pack/ connector pack] or directly from Digi-key etc.
<div class="res-img">
[[File:Connectors-all.png]]
</div>
Four pin male: TBP01P1-508-04BE [[https://www.digikey.com/en/products/detail/cui-devices/TBP01P1-508-04BE/10238369 | Digi-key]]

Two pin male: TBP01P1-508-02BE [[https://www.digikey.com/en/products/detail/cui-devices/TBP01P1-508-02BE/10238367 | Digi-key]]

=Klipper Configuration=
There are no jumpers on Recore and no hard fuses. Everything is software configurable and resettable from software. This gives great power and flexibility without requiring physical access to the board once it has been installed. But with great power comes great responsibility. It is possible to break things if care is not taken during setup. There is one setting in particular that is worth mentioning: ES0 can have either +5V or +12V on the power pin. This is in order to allow a standard industrial inductive sensor to be used on that end stop. If a 5V only peripheral is connected, that could damage the connected peripheral.

The default config file for Recore A6 can be found in the repository: [https://github.com/intelligent-agent/klipper/blob/master/config/generic-recore-a6.cfg generic-recore-a6.cfg]

===TMC2209===
The 6 stepper drivers on Recore are of type TMC2209 from Trinamic. Each stepper has a configuration interface with a bidirectional UART port that is connected to a peripheral UART on the A64. The peripheral is not in use, but instead the GPIO bit-banging functionality of Klipper is used to communicate with the stepper drivers.

Here is a table with pins and addresses for the steppers
{| class="wikitable"
!colspan="3"|Stepper driver config
|-
|Name
|Pins
|Address
|-
|S0
|PB0/PB1
|0
|-
|S1
|PB0/PB1
|1
|-
|S2
|PB0/PB1
|2
|-
|S3
|PB0/PB1
|3
|-
|S4
|PD0/PD1
|0
|-
|S5
|PD0/PD1
|1
|-
|S6
|PD0/PD1
|2
|-
|S7
|PD0/PD1
|3
|-
|}

=== External stepper drivers ===
<div class="res-img">
[[File:Ext-driver.png]]
</div>
It is possible to connect up to two external stepper drivers to Recore in addition to the 6 divers installed on the board.
These can be connected using the headers S6 and S7.

==Temperature inputs==
4 different temperature devices can be connected to the 4 analog inputs on Recore. Thermistor, Thermocouple, PT100 with INA826 and PT1000 without the use of a pre-amplifier.
===Thermistor===
<div class="res-img">
[[File:Thermistor.png]]
</div>
Make sure the pull-up is enabled and the op-amp gain is set to 1.

===Thermocouple===
<div class="res-img">
[[File:Thermocouple.png]]
</div>

Make sure the pull-up is disabled and the op-amp gain is set to 100.
<pre>
[recore]
...
gain_t0: 100
pullup_t0: 0
offset_t0: 1

[Extruder]
...
sensor_type: Type K
</pre>

===PT100 with INA826===
<div class="res-img">
[[File:PT100.png]]
</div>

In order to use a PT100 sensor, an external amplifier board must be used. There is an example configuration for Klipper that
uses this. The ADC reference voltage is 5.0 by default, but for Recore it is 3.3 V. Here is an example:
<pre>
[Extruder]
...
sensor_type: PT100 INA826
adc_voltage: 3.27
</pre>

The pull-up must also be disabled.

===PT1000===
<div class="res-img">
[[File:PT1000.png]]
</div>
Make sure the pull-up is enabled and the gain is set to 1. In the latest version, the sensor must be prefixed with RECORE.
<pre>
[Extruder]
...
sensor_type: PT1000
pullup_resistor: 4750
</pre>

=Connecting other sensors=
The board has been designed to work with a range of 3rd party sensors for automating the print.
==BLtouch==
There are two versions of the BLtouch, the difference is the color of one of the GND wires.
<div class="res-img">
[[File:Antclabs BLtouch sensor wiring.png]]
</div>
The Creality version has a blue GND wire.
<div class="res-img">
[[File:Creality BLtouch sensor wiring.png]]
</div>
<div class="alert alert-warning">
===='''Note'''====
There have been some cases of bad quality control for the Creality BLTouches, where the pinout on the sensor side have not matched the color coding in the photos/documentation. It might be good to make sure the color codes match up. For the Creality it should be, from left to right:
Blue, red, yellow, black, white.
</div>

When connected per wiring diagram above, setting up BLtouch can be done by adding the following section to printer.cfg.
<pre>
[bltouch]
sensor_pin: ar100:PH6
control_pin: !PB3
speed:15
samples:1
pin_move_time: 0.675
sample_retract_dist: 10
probe_with_touch_mode: true
stow_on_each_sample: false
x_offset:29.2
y_offset:-34
z_offset:0
</pre>

==Inductive Sensor ==
<div class="res-img">
[[File:Inductive sensor wiring 2.png]]
</div>
Connect the inductive sensor on ES0. You can choose either 5V or 12V output on the voltage pin. Inductive sensors often come with an industry standard voltage input of 6-36 V. For this reason there is a 12 V LDO (Low drop-out) voltage regulator integrated on the board. This voltage regulator can be output on the V+ pin of the connector marked ES0. If the Input to the board is 12 V, the LDO will supply a lower voltage, around 10.6 or so.

==ADXL345==
<div class="alert alert-warning">
===='''Note'''====
The ADXL345 seems to cause Klipper to shut down when trying to calibrate at a high rate. A workaround is to use a Pi Pico or similar MCU to communicate with the ADXL345, or to lower the rate. It's been tested working at 400, but not 800 which is the recommended minimum.
</div>

<div class="res-img">
[[File:Wiring.png]]
</div>
A popular accelerometer sensor for doing input shaping with Klipper is the ADXL345. This can be connected to the connectors S6/S7. There is no hardware SPI interface available, but a software implementation in Klipper exists.
Note: Only experimental support has been tested for this.
https://learn.adafruit.com/adxl345-digital-accelerometer

Config:
<pre>
[adxl345]
cs_pin: ar100:PL11
spi_software_sclk_pin: ar100:PL10
spi_software_mosi_pin: ar100:PE15
spi_software_miso_pin: ar100:PE14
rate: 400

[resonance_tester]
accel_chip: adxl345
probe_points:
100, 100, 20 # an example

</pre>

Using a Raspberry Pi Pico:
<pre>
[adxl345]
cs_pin: pico:gpio17
spi_bus: spi0c
</pre>

==RC Servo==
<div class="img-res">
[[File:RC-servo.png]]
</div>
Endstop 1 and 2 can be used as PWM outputs with 5V levels. Rev A6 is the first board with support for this.
More testing and configuration documentation is needed.

==Filament runout sensor==
<div class="img-res">
[[File:Filament-runout-sensor.png]]
</div>
Any of the 6 end stops can be used for connecting a filament runout sensor

=Software for Recore=
Recore comes with the Linux distro Refactor (Armbian) pre-installed on the eMMC.
For more instructions about software for Recore, see the Refactor wiki page:
[[ Refactor#Recore ]]

=== AR100 ===
Please see: [[AR100]]

=== Manual control and testing ===
https://wiki.iagent.no/wiki/Manual_control_and_testing

=Performance=
==Start-up time==
With a maximum clock for MMC2 of 200 MHz, here is the start-up time:
<pre>
root@recore-3:~# systemd-analyze
Startup finished in 5.128s (kernel) + 11.567s (userspace) = 16.695s
graphical.target reached after 11.421s in userspace
</pre>

==Measured voltages==
The final stages of Recore manufacturing consists of testing, calibration and flashing of firmware.
The calibration stage measures a number of voltages on the board and classifies the input stages gain and offset.
Instruments used:
* HP 3458A, 8.5 digit multimeter
* HP 3245A, Universal Source

====Microcontroller voltages====
VDDA uC: 3.312 V<br>
VDD uC: 3.312 V

Voltage from the PMIC supplied as bias:<br>
0.706 V <br>

====5V Buck converter ripple and noise ====
The 5V step down/Buck converter is a AOZ2151PQI-10. It can provide 4A and has an input voltage range of 12-28V.
It is hard wired to be in PWM mode. PFM mode results in a loud whine.

Below is a screenshot of the ripple and noise across the the 5V rail with a normal kernel running.
<div class="res-img">
[[File:VCC-5V-ripple-A4.png]]
</div>

===Input stage===
An experiment with a constant current load drawing 20 A from the bed connector with and without a 92 mm fan on top of the board for forced convection. The temperature measured was with the on board thermistor. Using a thermal camera, the temperature displayed matches well with the temperature reported by the camera. However, in Rev A2, this is not the hottest point on the board. The MOSFET controlling the bed seems to consistently get the highest temperature. The reason for this is probably due to a 3.3 V VGS.

<div class="res-img">
[[File: Temperature-fan-off.pdf.png]]
</div>
<div class="res-img">
[[File:Temperature-fan.pdf.png]]
</div>

====Inrush current====
During turn on of the high power stage, there will be an inrush current to charge up the bank of capacitors present on the board.
If no loads are turned on, the inrush current reaches 48 A at peak. This is important to consider when setting the current limit with device tree. Below is a trace of the current draw of Recore A6 when the input is enabled.

<div class="res-img">
[[File:Inrush-curent-A6-6-steppers.png|center]]
</div>

There are 3 different sensors present in the input stage for making sure the 12-24 V domain on the board does not overheat during startup and operation.
# The Fast acting over current protection is to ensure that the high power domain is disabled in the case of a short circuit condition.
# The current limit set in Klipper monitors the continuous current draw. This is now set at 20 A, but can go up to 30 A and still be within the limits of the connectors and input stage mosfets.
# The over temperature protection monitors the temperature in the input stage and cuts the power if the temperature goes over 110 degrees. The board should not be kept at this temperature for a prolonged period, but during heated bed heat-up, it can be elevated compared to the rest of the print.

Below is a plot of what the current on the input looks like if there is an over current condition on the high power domain as that domain is turned on.
<div class="res-img">
[[File:Over-current-short-circuit-50A.png|center]]
</div>

===ADC offset and gain measurements===
To measure the ADC offset error, measure the voltage on the uC input pin and record when the
transition from 0 to 1 occurs. It should occur at 0.5 LSB = 3.3/4096/2 = 0.4028 mV.
Offset: 55.35 mV - 0.4028 mV = 54.95 mV

==Temperature calibration==
A set of experiments have been carried out to calibrate the different sensors using a dry-well calibrator.
The reference probe was a Sensing Devices SDL385 PRT.
The levels of calibration was: room temperature, 50, 100, 150, and 200 degrees C.

===Thermistor===
The thermistor in use was a standard EPCOS 100K B57560G104F. This thermistor has a resistance tolerance of 2 %. The value of the pull-up resistor as measured during calibration was 4740.17501. This value seemed to work well at all levels of calibration, although a little on the high side compared to the reference.

===PT1000===
The PT1000 in use was a Heraeus 31500989 [https://www.heraeus.com/media/media/hne/datasheets/sensor_assemblies_1/Heraeus_W-EYK_Sensor_E.pdf] works well. The tolerance class given in the datasheet is "F 0.10 / Class 1/3 B". There are two different tolerances here: F0.10 and one third of Class B. The accuracy looks good at all temperatures, perhaps a bit on the high side if using the calibrated value for the pull-up. During the testing, 10 ohm was subtracted from the calibrated value.

===PT100===
The PT100 used in the calibration was the E3D PT100 with the INA826 amplifier board. There is no datasheet available for the PT100 sensor and no mention of what tolerance there is on the reference resistors used. Furthermore Klipper expects the reference voltage to be 5V exactly, and there is no way to supply a measured value. Measurements on Recore has shown that the value is often a bit lower due to the PMIC for the 5V output on the "input" ports. 4.979 V has been measured and is likely an expected value.

===Thermocouple===
Using the calibration values directly will give a slight offset to the thermocouple measurements.
The gain and ADC voltage can be used as measured during calibration. It should be in the region of 101 for gain and 3.307 for ADC voltage. As for the offset, that can be increased slightly to compensate for the cold junction temperature difference. For instance, the measured offset for the test board was 0.0032960, but a value of 0.00340 fit the data points well. The measurements were done on T2, so it it possible that the distance from the cold junction caused the offset. The cold junction thermistor is located between T0 and T1.

=FAQ=
====Where can I ask for help?====
:You can join the Discord: https://discord.gg/bCnp9H5SB5
====What comes in the box with the Recore? Specifically, terminal connectors for power, etc?====
:It's only the board, no cables or connectors. There is a bag of connectors available to purchase in the web shop.
====Do I need access to those 3 buttons on the board?====
:It is not necessary to have access to the three buttons for normal use.
====What's the maximum current draw for heat bed?====
:This has been tested up to 20 A
====Why are there unused and unbroken out pins on the STM32 MCU?====
:The pins that are needed from the MCU have been routed out plus two pins available on an external header.
====I have a gadget that I want to connect with SPI. Is that possible?====
:There are 6 pins available from the main SoC that can be used for various things.There is no hardware SPI, but you can make a program that uses soft SPI. There is no dedicated I2C, but perhaps that would be a nice addition.

====What exactly is the role of the AR100 device?====
:The AR100 handles the fast real-time aspects, mainly the stepper motors and end stops.

====What voltage fans are supported?====
:The same voltage as the input voltage, either 12 V or 24 V. You can experiment with PWM for running lower voltage fans on 24 V input.
====Where is the board layout file?====
:The Layout file will not be available. It is an "open schematic" board, not open source hardware
====Where are you shipping from?====
:Boards are shipping from Norway. Eventually shipping will be from a warehouse in the US

= Known hardware issues for rev A6=
===T1 offset is not consistent===
:On Rev A6, during calibration it has been discovered that the offset on T1 is often varying around the predetermined set point of 0.33 V. It seems the cause of this is the batch of op-amps used, so it is a hardware issue. The good news is that it seems to be OK to use the values from the calibration document. The gain should be about the same (101).

===Board can not handle 24 V input (fixed)===
[[File:Connector with capacitor.jpg|thumb|Connector with capacitor]]
[[File:Board with capacitor.jpg|thumb|Board with capacitor]]
:The design without alterations can not handle 24 V input. A bare board can only handle about 20 V. A workaround is to add an electrolytic capacitor to the input. This can either be soldered on to the step down converter input MLCC capacitors, or it can be screwed directly on to the input connector. Be aware of the polarity of the capacitor when mounting it. The "minus" should be towards the black wire. The recommended value is a 47 uF capacitor with a voltage rating of 35 V or higher. 33 uF has also been tested and working. 100 uF and higher should also work, but has not been tested specifically.

:The capacitor that will be added to remaining boards from the Rev A6 batch is ESH476M035AE3AA from Kemet: https://www.digikey.com/en/products/detail/kemet/ESH476M035AE3AA/2712504

:It seems the reason for the issue is a combination of long wires with high inductance, too low capacitance on the input of the board and too little headroom on the step down converter. This can cause voltage spikes that makes the input voltage go above the rated input voltage during load changes. Adding a capacitor to the input "buffers" or "decouples" the long inductance wires and limits the voltage spikes.

===USB connectors not discovered when powered by USB device (workaround)===
:Some boards are not initialized right when powered by only the USB port. The reason for this is that the VBUS/over current input on the USB hub can get an ambiguous value from USB connector 2 and 3 (the two USB host connectors close to the ethernet connector).
:A workaround is to apply power to the VIN (12-24V) connector first. If FEL-mode is necessary, that button must be pressed as power is applied from the VIN connector. After that the USB connector can be inserted.

Rebuild v1.2.0

2026-10-01T16:37:07Z

Elias: System updates in Fluidd/Mainsail with tested kernel releases; install with Reflash v1.2.0 or newer

__NOINDEX__
<div class="alert alert-danger">
===='''Draft - Rebuild v1.2.0 has not been released'''====
This page collects the documentation for the next release while it is being built. The changes it describes are on development branches and may still change. For the current release, see [[Rebuild v1.1.0]].
</div>

[[File:Rebuild header.png|center]]
Rebuild is a complete Linux image for [[Recore A8|Recore]] 3D printer controller boards. Rebuild comes with Klipper installed and the choice of either [https://docs.mainsail.xyz/ Mainsail], [https://docs.fluidd.xyz/ Fluidd] or [https://octoprint.org/ OctoPrint].

=What is new in v1.2.0=

==Rebuild's own files are Debian packages==
Everything Rebuild adds to the base system is now installed from two packages, rather than copied into the image by the build scripts:
* '''rebuild-recore''', on every image including barebone: the board tools (<code>get-serial-number</code>, <code>get-recore-revision</code> and friends), the USB-C serial console, and the Wi-Fi hotspot fallback.
* '''rebuild-printer''', on the Fluidd, Mainsail and OctoPrint images: the tools that flash the AR100, STM32 and RP2040 firmware, the configurations that firmware is built from, first boot, SSH auto-disable, the boot splash, and the system settings the printer images share.

This means that a fix to any of these files can reach a board through <code>apt upgrade</code>, instead of requiring a new image and a reflash.

The tools have moved from <code>/usr/local/bin</code> to <code>/usr/bin</code>. On a board that is upgraded in place, the old paths keep working: they become links to the new ones. The files the old image had copied in are kept in <code>/var/backups/rebuild-legacy</code>.

==System updates==
Rebuild v1.2.0 can be updated in place, without reflashing. Updates appear under '''System''' in the update section of Fluidd and Mainsail, and install from there:
* Updates to Debian, including security fixes.
* Updates to Rebuild's own packages ('''rebuild-recore''' and '''rebuild-printer''').
* New versions of the Linux kernel and device trees, '''once they have been tested on Recore hardware'''. The kernel, device trees, U-Boot and the other Armbian packages are pinned to tested versions by the package '''rebuild-armbian-tested'''. A newer version of that package releases a newer kernel.

A kernel release arrives in two steps: the first update installs the new '''rebuild-armbian-tested''', and the next one shows the kernel and its companion packages. Reboot after a kernel update.

The bootloader (U-Boot) is not updated this way. It stays as it was when the board was installed.

Klipper, Moonraker, Fluidd, Mainsail and KlipperScreen are updated in the same place as before, each with its own entry.

==Security==
* The '''printer''' account is now a service account. It has no password, is not in the <code>sudo</code> group, and cannot log in over SSH. Klipper, Moonraker and KlipperScreen keep working: the rights they need are given to them explicitly. Log in as '''debian''', and use <code>sudo -u printer -i</code> to work in Klipper's files, as before.

==Klipper and the AR100==
* Klipper is updated to '''v0.13.0-786'''. This version includes the AR100 improvements made for this release, which are now part of Klipper itself: the timer and message handling rework from Klipper's maintainer, faster serial handling, and building at <code>-O2</code> with a correct size check. The AR100 firmware is built from an unmodified Klipper.
* The AR100 compiler is updated from GCC 15.1.0 to '''GCC 16.1.0''', which includes fixes for code generation errors on OpenRISC (64-bit and 16-bit shifts, and branch placement).
* Each firmware file in <code>/opt/firmware</code> now has the exact configuration it was built with next to it (<code>ar100.config</code>, <code>stm32.config</code>, <code>stm32-32KB.config</code>, <code>rp2040.config</code>), and <code>klipper-version</code> records the Klipper version they were built from.

===How fast the AR100 can step===
The AR100 drives the X/Y (A/B) steppers, and the rate at which it can produce step pulses limits the top speed for a given microstep setting. With the improvements above it can step two steppers at the same time about '''3.4 times faster''' than before: one step every 247 AR100 clock cycles per stepper instead of every 836, or about 1.2 million steps per second per stepper instead of 360,000.

What that means for speed depends on the number of steps per mm. The figures below are for a '''Voron 2.4''' (CoreXY, 1.8° motors, 20-tooth GT2 pulleys, <code>rotation_distance: 40</code>, so 5 full steps per mm). On CoreXY the worst direction is a 45° diagonal, where one motor turns √2 times faster than the toolhead moves, so the speed column is the top speed in any direction.

{| class="wikitable"
! Microsteps !! Steps per mm !! Top speed, any direction, before !! Top speed, any direction, now !! Now, with 30% margin
|-
| 16 || 80 || 3,200 mm/s || 10,700 mm/s || 7,500 mm/s
|-
| 32 || 160 || 1,600 mm/s || 5,400 mm/s || 3,800 mm/s
|-
| 64 || 320 || 790 mm/s || 2,700 mm/s || 1,900 mm/s
|-
| 128 || 640 || 400 mm/s || 1,300 mm/s || 940 mm/s
|-
| 256 || 1,280 || 200 mm/s || 670 mm/s || 470 mm/s
|}

* Use the column with margin when choosing settings: the limit is where the AR100 shuts down with <code>Timer too close</code>, and a real print adds work the measurement does not.
* For another printer, scale by its steps per mm: halving the steps per mm doubles the top speed.
* Speed is rarely the only limit. On the Voron 2.4 used for these measurements, the mechanics stopped at 20,000 mm/s² acceleration (25,000 stalled the motors at 2.0 A), well before the AR100 did.
* TMC drivers interpolate to 256 microsteps internally (<code>interpolate: True</code>, the default), so 32 or 64 microsteps still run smoothly.

Measured on the Voron 2.4 with the same AR100 changes on test firmware, before they were merged into Klipper, using a load test that streams commands while stepping. With them, the Voron completed 5 of 5 homings at 256 microsteps (upstream failed 2 of 3) and a dry-run Benchy at 32 microsteps, 800 mm/s and 20,000 mm/s² with no retransmissions. The figures will be checked again on the released image.

==Fixes==
* A reboot shortly after the board has started no longer hangs for 90 seconds. Moonraker is given 10 seconds to stop.

==A smaller image==
* '''Input shaper graphs are no longer drawn on the printer by default.''' <code>python3-matplotlib</code> is not installed, which saves 242 MB. Klipper itself never used it. See [[#Input shaper graphs|Input shaper graphs]] below.
* The ARM compiler no longer carries libraries for Cortex-A and Cortex-R processors, which Klipper never builds for, and the firmware package no longer carries firmware for Qualcomm processors. Together these save about 630 MB. Every Cortex-M variant is kept, so firmware for any microcontroller Klipper supports can still be built on the printer, with any options (CAN bus, USB to CAN bridge, and so on).

===Image sizes===
{| class="wikitable"
! Image !! Download (compressed), v1.1.0 !! Download, v1.2.0 !! Image unpacked, v1.1.0 !! Image unpacked, v1.2.0 !! Used on the Recore, v1.1.0 !! Used on the Recore, v1.2.0
|-
| Barebone || 332 MB || '''224 MB''' (−33%) || 1.84 GB || 1.45 GB || 1.34 GB || '''1.02 GB''' (−24%)
|-
| Fluidd || 1.01 GB || '''751 MB''' (−25%) || 6.09 GB || 4.67 GB || 4.83 GB || '''3.66 GB''' (−24%)
|-
| Mainsail || 997 MB || '''755 MB''' (−24%) || 6.09 GB || 4.67 GB || 4.83 GB || '''3.66 GB''' (−24%)
|-
| OctoPrint || 1.01 GB || '''751 MB''' (−25%) || 5.96 GB || 4.53 GB || 4.73 GB || '''3.56 GB''' (−25%)
|}
* '''Download''' is the <code>.img.xz</code> file that Reflash fetches and writes.
* '''Image unpacked''' is the size of the image once decompressed. Reflash writes it to the eMMC and then grows the root partition to fill it, so this is not the space taken on the board.
* '''Used on the Recore''' is the space the installed system takes on the eMMC: the boot and root file systems together, as built. The rest of the 8 GB eMMC is free for your files, logs and G-code. A board shows slightly less in <code>df</code>, which leaves out file system overhead, and slightly more after first boot.
* v1.2.0 figures are from the development build v1.1.0-26-g2334760, and may change before release.

=Getting started=

==Install with Reflash v1.2.0 or newer==
Install Rebuild v1.2.0 with '''[[Reflash]] v1.2.0 or newer'''; older versions of Reflash are not supported for it. They select the board's device tree with a link that kernel updates replace, and a board on the generic device tree can lose parts of the hardware - on an A6, Klipper could no longer reach the STM32. Rebuild v1.2.0 converts such a board when a kernel update arrives, but only installs from Reflash v1.2.0 are tested.

To check how a board selects its device tree, log in as '''debian''' and run:
<pre>
grep fdtfile /boot/armbianEnv.txt
</pre>
If nothing is printed, set the device tree for the board's revision once:
<pre>
sudo update-recore-revision
</pre>

==Building firmware on the printer==
The configurations Rebuild uses for its own firmware are installed with the image, in <code>/usr/share/rebuild/firmware</code>. To rebuild the STM32 firmware for a Recore A8 (32 KB flash):
<pre>
sudo -u printer -i
cd ~/klipper
cp /usr/share/rebuild/firmware/stm32f031-32KB-serial.config .config
make olddefconfig
make
exit
</pre>
The same directory has <code>stm32f031-serial.config</code>, for the 16 KB STM32 on earlier boards, and <code>ar100.config</code>. Flashing works as described in [[Rebuild v1.1.0#Flashing STM32 firmware|v1.1.0]].

<div class="alert alert-warning">
===='''Use one or two build jobs'''====
A Recore without a fan can reach its critical temperature with all four cores compiling, and it then powers itself off. Build with <code>make -j2</code> or plain <code>make</code>, not <code>make -j4</code>.
</div>

===AR100 toolchain===
The AR100 firmware is compiled with an OpenRISC GCC toolchain installed in <code>/opt/or1k-elf</code>. v1.2.0 uses GCC 16.1.0, binutils 2.46 and newlib 4.6, built for the Recore from OpenRISC's own build scripts. The build and the changes made for Rebuild are in [https://github.com/intelligent-agent/or1k-toolchain-build/tree/rebuild intelligent-agent/or1k-toolchain-build] (branch <code>rebuild</code>), and the toolchain is downloaded from http://feeds.iagent.no/toolchains/.

==Input shaper graphs==
Klipper's resonance measurement does not need anything extra. <code>SHAPER_CALIBRATE</code> runs inside Klipper, measures both axes, recommends a shaper for each and saves it with <code>SAVE_CONFIG</code>. That works on v1.2.0 exactly as before.

The '''graphs''' are optional. They are drawn by Klipper's scripts (<code>scripts/calibrate_shaper.py</code>, <code>scripts/graph_accelerometer.py</code>), which need the Python plotting library <code>matplotlib</code>. v1.2.0 no longer installs it. There are two ways to get graphs.

===Draw the graphs on your computer (recommended)===
The picture is looked at on a computer anyway, so draw it there. First measure on the printer, from the console in Fluidd or Mainsail:
<pre>
TEST_RESONANCES AXIS=X
TEST_RESONANCES AXIS=Y
</pre>
Klipper writes the measurements to <code>/tmp/resonances_x_*.csv</code> and <code>/tmp/resonances_y_*.csv</code> on the printer. Copy them to your computer:
<pre>
scp debian@recore.local:/tmp/resonances_*.csv .
</pre>
Then, on the computer, with Python 3 installed:
<pre>
git clone https://github.com/Klipper3d/klipper
python3 -m pip install numpy matplotlib
python3 klipper/scripts/calibrate_shaper.py resonances_x_*.csv -o shaper_calibrate_x.png
python3 klipper/scripts/calibrate_shaper.py resonances_y_*.csv -o shaper_calibrate_y.png
</pre>

===Install matplotlib on the printer===
If you would rather draw the graphs on the printer, as described in [https://www.klipper3d.org/Measuring_Resonances.html Klipper's documentation], install matplotlib first, logged in as '''debian''':
<pre>
sudo apt update
sudo apt install python3-matplotlib
</pre>
This takes about 240 MB. Klipper's scripts then work as described in its documentation.

Plugins that draw these graphs themselves, such as Shake&Tune, install their own copy of matplotlib and do not need either step.

Rebuild v1.2.0

2026-10-01T15:00:07Z

2026-08-23T17:30:07Z

Elias: Correct board to A7 and add build number; add section on one camera (shipped ustreamer) vs several (crowsnest)

Recore can run one or more USB webcams for monitoring prints. This page covers how to choose a camera, how many will work at once, and how to diagnose the common failures.

All figures on this page were measured on a '''Recore A7''' running '''<code>rebuild-fluidd-1adfb1e</code>''' (kernel 6.18.33) in August 2026, with three USB cameras attached.

== The short version ==

* '''Buy a camera that supports MJPEG in hardware.''' This matters more than resolution, brand or price. A camera without it can cost 20x the USB bandwidth and forces the CPU to compress every frame.
* '''Roughly three cameras at 640x480, or two at 1280x720.''' The limit is USB bandwidth, not the processor.
* If a camera will not start, check <code>dmesg</code> for <code>Failed to submit URB 0 (-28)</code> before suspecting anything else.

== One camera, or several ==

'''One camera works out of the box.''' Rebuild ships [https://github.com/pikvm/ustreamer ustreamer] and a udev rule that creates <code>/dev/webcam</code> for the first USB camera it finds. Plug a camera in and it is served on port 8080 as <code>/webcam/</code>, with nothing to configure. This is handled by <code>ustreamer.service</code>, which starts automatically when a camera appears.

'''Several cameras need [https://docs.mainsail.xyz/crowsnest/ crowsnest], which is not included in the image.''' The shipped ustreamer service is hard-wired to one device and one port:

<pre>
ExecStart=/home/printer/ustreamer/ustreamer --device /dev/webcam --host=0.0.0.0 --port=8080 -m MJPEG
</pre>

Crowsnest is a supervisor that launches one streamer process per camera, each on its own port, from a single configuration file. Moonraker already permits controlling it - it is listed in <code>moonraker.asvc</code> - so it can be installed without further changes to the image.

When installing crowsnest, '''disable the shipped ustreamer service first'''. Otherwise the two compete for the same camera and for port 8080:

<pre>
sudo systemctl disable --now ustreamer
</pre>

{| class="wikitable"
! !! One camera !! Several cameras
|-
| Software || ustreamer (shipped) || crowsnest (installed separately)
|-
| Configuration || none needed || <code>~/printer_data/config/crowsnest.conf</code>
|-
| Ports || 8080 only || 8080, 8081, 8082, ...
|-
| URLs || <code>/webcam/</code> || <code>/webcam/</code>, <code>/webcam2/</code>, <code>/webcam3/</code>
|}

The rest of this page applies to both, except where crowsnest configuration is shown explicitly.

== Why MJPEG matters ==

USB cameras deliver frames in one of two ways:

* '''MJPEG''' (<code>MJPG</code>) - the camera compresses each frame itself. The Recore copies compressed frames straight to the browser without touching them.
* '''Raw''' (<code>YUYV</code>) - the camera sends uncompressed pixels. Every frame must then be JPEG-compressed in software on the Recore's CPU.

A single 640x480 raw frame is 614 kB. The same frame as MJPEG is typically 20-40 kB. That difference applies to both the USB bus and the processor.

Measured on the same board, same bus:

{| class="wikitable"
! Camera !! MJPEG? !! Result
|-
| Logitech BRIO || yes || 1280x720 @ 54 fps, hardware passthrough
|-
| AUKEY PC-W1 || yes || 1280x720 @ 30 fps, hardware passthrough
|-
| Vimicro "Venus" || '''no''' || never obtained USB bandwidth alongside the others, even at 320x240
|}

The raw-only camera could not be made to work as a third camera at any resolution. It was not scaling its USB bandwidth request with frame size.

=== Checking a camera before buying ===

If you can plug it into any Linux machine:

<pre>
v4l2-ctl --list-formats-ext -d /dev/video0
</pre>

Look for this line:

<pre>
[1]: 'MJPG' (Motion-JPEG, compressed)
</pre>

If only <code>'YUYV'</code> appears, the camera has no hardware compression. It will work as a single camera at low resolution, but it is a poor choice for a Recore.

Some cameras also list <code>H264</code> or <code>HEVC</code>. These are not currently used - the streaming software (ustreamer) handles MJPEG only - but a camera offering H.264 will almost always offer MJPEG as well.

== How many cameras can run at once ==

The A64 has a '''single USB host controller''', and every USB device on a Recore sits behind one hub connected to it. USB 2.0 reserves bandwidth for cameras up front, when the stream starts, and the total is fixed.

Measured with three MJPEG cameras:

{| class="wikitable"
! Configuration !! Result
|-
| 3 cameras @ 640x480 || '''all three work''' - 27, 20 and 30 fps
|-
| 3 cameras @ 1280x720 || only the first starts; other two fail immediately
|-
| 2 cameras @ 1280x720 || both work - 53 and 30 fps
|-
| 2 cameras @ 1920x1080 || first works, second fails
|}

Bandwidth is claimed on a first-come basis. Whichever camera starts first gets what it asks for, and later cameras get whatever is left - which may be nothing.

=== The signature of running out of bandwidth ===

<pre>
$ dmesg | grep URB
uvcvideo 1-1.3:1.1: Failed to submit URB 0 (-28).
uvcvideo 1-1.1:1.1: Failed to submit URB 0 (-28).
</pre>

<code>-28</code> is <code>ENOSPC</code>. In this context it does not mean disk space - it means the USB controller could not reserve enough bandwidth for the stream.

This failure is '''immediate and unrelated to system load'''. If a camera fails this way it will fail on an idle machine just as reliably. The fix is to lower resolution or frame rate, or to use fewer cameras.

== CPU cost ==

With hardware MJPEG the CPU cost is close to nothing. Three cameras at 640x480, all three being watched in Fluidd:

<pre>
cpu0 9% cpu1 5% cpu2 8% cpu3 6% (softirq 0% on all cores)

ustreamer processes: ~3.6% each, about 11% of one core in total
klipper (python): 7.7% <- more than all three cameras combined
</pre>

Every frame captured reached the browser (<code>queued_fps</code> equalled <code>captured_fps</code> on all three streams), so nothing was being dropped.

A raw YUYV camera changes this picture completely, because ustreamer must then run a software JPEG encoder - it starts four worker threads for a single 640x480 stream.

'''Conclusion:''' on a Recore, multiple cameras are limited by USB bandwidth, not by the processor. Three cameras left the SoC around 90% idle.

== Low frame rate from a single camera ==

If one camera runs far below its rated frame rate, the cause is usually '''exposure time''', not bandwidth.

In dim light a camera on automatic exposure will lengthen its exposure, and exposure time puts a hard ceiling on frame rate: 140 ms per frame is at most 7 fps, no matter what else is configured.

Measured on a Vimicro camera at 640x480 (Recore A7):

{| class="wikitable"
! Setting !! Frame rate
|-
| auto exposure (default) || 7.2 fps
|-
| <code>exposure_time_absolute=100</code> (~10 ms) || 19.9 fps
|-
| <code>exposure_time_absolute=30</code> (~3 ms) || 30.0 fps
|}

Note the trade-off: shorter exposure means a darker image. More light on the subject is the better fix where possible.

'''The diagnostic that distinguishes the two causes:''' lower the resolution and re-measure.
* Frame rate improves roughly in proportion - the limit was '''bandwidth'''.
* Frame rate does not change - the limit is '''exposure''' (or something else per-frame).

In the case above, 320x240 gave exactly the same 7 fps as 640x480, which ruled out bandwidth before anything was changed.

Setting exposure manually in crowsnest:

<pre>
[cam 1]
v4l2ctl: auto_exposure=1,exposure_time_absolute=100
</pre>

== Configuration ==

=== Use stable device paths ===

Do '''not''' use <code>/dev/video0</code>, <code>/dev/video2</code> and so on in configuration. These numbers change whenever a camera is added, removed or replugged - on the test board <code>/dev/webcam</code> moved from <code>video2</code> to <code>video5</code> to <code>video7</code> in a single afternoon as cameras were swapped, silently changing which camera was being streamed.

Use the by-id path instead:

<pre>
$ ls /dev/v4l/by-id/
usb-046d_Logitech_BRIO_E76A9283-video-index0
usb-Sonix_Technology_Co.__Ltd._AUKEY_PC-W1_SN0001-video-index0
</pre>

<code>index0</code> matters: a UVC camera exposes several device nodes and only the first is the capture device. The BRIO exposes four; the rest carry metadata.

=== Example crowsnest configuration ===

Three cameras, all MJPEG, at a resolution where all three fit:

<pre>
[crowsnest]
log_level: verbose
rollover_on_start: false
no_proxy: false

[cam 1]
mode: ustreamer
port: 8080
device: /dev/v4l/by-id/usb-046d_Logitech_BRIO_E76A9283-video-index0
resolution: 640x480
max_fps: 30
custom_flags: --format=MJPEG --drop-same-frames=30

[cam 2]
mode: ustreamer
port: 8081
device: /dev/v4l/by-id/usb-Sonix_Technology_Co.__Ltd._AUKEY_PC-W1_SN0001-video-index0
resolution: 640x480
max_fps: 30
custom_flags: --format=MJPEG --drop-same-frames=30

[cam 3]
mode: ustreamer
port: 8082
device: /dev/v4l/by-id/usb-Linux_Foundation_Webcam_gadget-video-index0
resolution: 640x480
max_fps: 30
custom_flags: --format=MJPEG --drop-same-frames=30
</pre>

Ports map to URLs: 8080 is <code>/webcam/</code>, 8081 is <code>/webcam2/</code>, 8082 is <code>/webcam3/</code>.

=== Adding cameras to Fluidd ===

Each camera has to be registered in Moonraker before it appears in the interface. In Fluidd: '''Settings -> Camera -> Add Camera''', then set the stream URL to <code>/webcam2/?action=stream</code> and the snapshot URL to <code>/webcam2/?action=snapshot</code>.

Choose service '''"MJPEG Stream"''' rather than '''"MJPEG Stream (Adaptive)"'''. In adaptive mode the browser fetches individual snapshots at its own pace instead of consuming the stream, and it throttles to <code>target_fps_idle</code> - 5 fps by default - whenever the printer is not printing. A camera capturing at 20 fps can appear to run at 2 fps for this reason alone, with nothing wrong on the Recore at all.

== Troubleshooting ==

{| class="wikitable"
! Symptom !! Likely cause !! Check
|-
| Second or third camera never starts || USB bandwidth || <code>dmesg | grep URB</code> for <code>-28</code>
|-
| Low fps, unchanged by lowering resolution || exposure time || <code>v4l2-ctl -d /dev/webcam --list-ctrls</code>
|-
| Low fps, improves when resolution is lowered || USB bandwidth || reduce resolution or camera count
|-
| Fluidd shows ~2-5 fps, board reports more || Fluidd adaptive mode || set service to plain "MJPEG Stream"
|-
| High CPU from ustreamer || camera has no MJPEG || <code>v4l2-ctl --list-formats-ext</code>
|-
| Camera works, then stops after replug || device path changed || use <code>/dev/v4l/by-id/</code>
|-
| All cameras stop after adding one || crowsnest crash - see below || <code>journalctl -u crowsnest</code>
|}

=== Useful commands ===

<pre>
# What formats and frame rates does this camera support?
v4l2-ctl --list-formats-ext -d /dev/video2

# What controls does it have (exposure, brightness, ...)?
v4l2-ctl --list-ctrls -d /dev/video2

# What is the stream actually doing right now?
curl -s http://localhost:8080/state

# Which USB devices are attached, and at what speed?
for d in /sys/bus/usb/devices/[0-9]*-[0-9]*; do
echo "$(basename $d) $(cat $d/speed)M $(cat $d/product 2>/dev/null)"
done
</pre>

The <code>/state</code> endpoint is the quickest way to see what is happening:

<pre>
"encoder": {"type": "HW"} <- hardware MJPEG, no CPU cost
"encoder": {"type": "CPU"} <- software encoding, camera has no MJPEG
"online": false <- camera not delivering frames at all
"captured_fps": 27 <- what the camera produces
"queued_fps": 27 <- what reaches viewers; lower means drops
</pre>

=== Known issue: one camera can prevent all others from starting ===

Crowsnest v5.0.11 crashes on startup if any attached camera exposes a V4L2 control without a <code>default</code> value, which is legal and occurs on some cameras:

<pre>
File "crowsnest/camera/types/uvc.py", line 72, in get_controls_string
line += f" default={data['default']}"
KeyError: 'default'
</pre>

The crash happens before '''any''' camera starts, so a single unusual camera takes down every stream on the machine. Changing the log level does not avoid it, because the controls are enumerated regardless.

Workaround, until fixed upstream - in <code>crowsnest/camera/types/uvc.py</code>:

<pre>
line += f" default={data.get('default', 'n/a')}"
</pre>

== Background: why the USB bus is the limit ==

The Allwinner A64 has one EHCI host controller. Every USB device on a Recore - cameras, WiFi dongles, USB storage, USB serial - shares it.

USB 2.0 gives cameras ''isochronous'' transfers: guaranteed, reserved bandwidth, claimed when the stream opens. The specification caps this at 80% of the bus, and the reservation is made up front based on the requested resolution and frame rate. This is why a camera either starts successfully or fails immediately, rather than degrading gradually.

It was previously suspected that USB interrupt handling on a single CPU core was the constraint. Measurement does not support this for cameras:

<pre>
$ grep ehci /proc/interrupts
57: 429 992573 0 0 GICv2 106 Level ehci_hcd:usb1
cpu0 cpu1
</pre>

The interrupt is handled on one core, but with three cameras streaming to three viewers that core was only 5% busy, and softirq time was zero across all cores.

'''However''', high single-core load ''has'' been measured on Recore when networking runs over a '''USB WiFi dongle''' - 73% of one core to receive 1.2 MB/s. In that case the USB completion handling and the entire network stack land on the same core. Cameras over Ethernet do not have this problem, because Ethernet on the A64 is a separate peripheral that does not use USB at all.

So: '''a Recore with cameras and a USB WiFi dongle is a meaningfully heavier configuration than one using Ethernet.''' If cameras behave badly over WiFi but well over Ethernet, this is why.

== H.264 and HEVC ==

Some cameras offer H.264 or HEVC in addition to MJPEG. These are '''far''' more efficient than MJPEG, but they '''cannot currently be used on Recore'''. This section records why, so the question does not need re-investigating.

=== The efficiency is dramatic ===

Measured on a 4K microscope camera, same board, same bus, 45 frames per run:

{| class="wikitable"
! Format !! Resolution !! Frame rate !! Per frame
|-
| MJPEG || 1920x1080 || 29.9 fps || 395 kB
|-
| '''H.264''' || 1920x1080 || 29.8 fps || '''18 kB''' (22x smaller)
|-
| H.264 || 3840x2160 || 26.3 fps || 89 kB
|-
| '''HEVC''' || 3840x2160 || '''30.0 fps''' || '''73 kB''' (25x smaller)
|-
| MJPEG || 3840x2160 || 12.7 fps || 1871 kB
|}

'''4K HEVC at a full 30 fps uses about five times less bandwidth than 1080p MJPEG.''' Note also that MJPEG at 4K cannot reach 30 fps at all - it manages 12.7 fps because it saturates the USB bus, while HEVC at the same resolution runs at the full rate.

If these codecs worked, the bandwidth limits described above would largely disappear.

=== Why it does not work ===

The blocker is '''camera-streamer''', not crowsnest and not ustreamer.

* '''ustreamer''' handles MJPEG only, by design. It is not the limitation, because crowsnest can launch camera-streamer instead.
* '''camera-streamer''' does support H.264 and captures it correctly - it negotiates <code>1920x1080/H264</code> without trouble - but it then fails to start:

<pre>
device/buffer_list.c: CAMERA:capture: Using: 1920x1080/H264, buffers=3 <- capture works
device/camera/camera_decoder.c: CAMERA: Cannot find 'H264' decoder
device/camera/camera_output.c: CAMERA: Cannot find source for 'SNAPSHOT' for one of the formats 'JPEG, MJPG'.
</pre>

Two things combine to make this a hard stop:

'''1. The snapshot output cannot be disabled.''' camera-streamer 0.4.2.4 provides <code>--camera-stream.disabled</code> and <code>--camera-video.disabled</code>, but there is no equivalent for snapshot. Snapshot must be JPEG or MJPG, so H.264 input has to be decoded to satisfy it. Disabling the other two outputs does not help - it still exits.

'''2. The A64's video decoder is the wrong kind.''' The SoC does have a hardware decoder (<code>cedrus</code>), and it does handle H.264 and HEVC, but note the formats it accepts:

<pre>
$ v4l2-ctl -d /dev/video0 --list-formats-out
[1]: 'S264' (H.264 Parsed Slice Data, compressed)
[2]: 'S265' (HEVC Parsed Slice Data, compressed)
</pre>

"Parsed Slice Data" means this is a '''stateless''' decoder. Userspace has to parse the bitstream itself, extract the sequence and picture parameter sets, and drive the hardware slice by slice through the Media Request API. camera-streamer expects a '''stateful''' decoder - the kind found on the Raspberry Pi, where a stream goes in and frames come out. These are fundamentally different programming models, so camera-streamer cannot use cedrus even though the hardware is capable.

This is not a missing driver, a missing package or a configuration mistake.

=== What would be needed ===

* '''Patch camera-streamer''' to allow the snapshot output to be disabled, then pass H.264 through to WebRTC without decoding at all. This is the smallest change and would deliver the bandwidth saving. The drawback is that WebRTC is the only viable output - Fluidd displays cameras with an ordinary image element, which cannot show H.264.
* '''Use a decoder that speaks stateless V4L2''' - ffmpeg with the Request API, or libva - to convert H.264 to MJPEG on the board. This keeps compatibility with existing interfaces, but re-introduces a per-frame cost, which is much of what the codec was meant to avoid.

Until one of those exists, '''use MJPEG''', and treat a camera's H.264 or HEVC support as a bonus that is not currently usable. A camera offering H.264 will almost always offer MJPEG too, so such cameras are still fine to buy.

== See also ==

* [https://github.com/intelligent-agent/Rebuild/issues/76 Rebuild issue #76] - USB interrupt handling and multi-camera investigation, with measurements
* [https://docs.mainsail.xyz/crowsnest/ Crowsnest documentation]

Webcams

2026-08-23T17:23:39Z

Elias: Add H.264/HEVC section: measured efficiency and why camera-streamer cannot use them on A64

Recore can run one or more USB webcams for monitoring prints. This page covers how to choose a camera, how many will work at once, and how to diagnose the common failures.

All figures here were measured on a Recore A5 running <code>rebuild-fluidd</code> (kernel 6.18.33) in August 2026, with three cameras attached.

== The short version ==

* '''Buy a camera that supports MJPEG in hardware.''' This matters more than resolution, brand or price. A camera without it can cost 20x the USB bandwidth and forces the CPU to compress every frame.
* '''Roughly three cameras at 640x480, or two at 1280x720.''' The limit is USB bandwidth, not the processor.
* If a camera will not start, check <code>dmesg</code> for <code>Failed to submit URB 0 (-28)</code> before suspecting anything else.

== Why MJPEG matters ==

USB cameras deliver frames in one of two ways:

* '''MJPEG''' (<code>MJPG</code>) - the camera compresses each frame itself. The Recore copies compressed frames straight to the browser without touching them.
* '''Raw''' (<code>YUYV</code>) - the camera sends uncompressed pixels. Every frame must then be JPEG-compressed in software on the Recore's CPU.

A single 640x480 raw frame is 614 kB. The same frame as MJPEG is typically 20-40 kB. That difference applies to both the USB bus and the processor.

Measured on the same board, same bus:

{| class="wikitable"
! Camera !! MJPEG? !! Result
|-
| Logitech BRIO || yes || 1280x720 @ 54 fps, hardware passthrough
|-
| AUKEY PC-W1 || yes || 1280x720 @ 30 fps, hardware passthrough
|-
| Vimicro "Venus" || '''no''' || never obtained USB bandwidth alongside the others, even at 320x240
|}

The raw-only camera could not be made to work as a third camera at any resolution. It was not scaling its USB bandwidth request with frame size.

=== Checking a camera before buying ===

If you can plug it into any Linux machine:

<pre>
v4l2-ctl --list-formats-ext -d /dev/video0
</pre>

Look for this line:

<pre>
[1]: 'MJPG' (Motion-JPEG, compressed)
</pre>

If only <code>'YUYV'</code> appears, the camera has no hardware compression. It will work as a single camera at low resolution, but it is a poor choice for a Recore.

Some cameras also list <code>H264</code> or <code>HEVC</code>. These are not currently used - the streaming software (ustreamer) handles MJPEG only - but a camera offering H.264 will almost always offer MJPEG as well.

== How many cameras can run at once ==

The A64 has a '''single USB host controller''', and every USB device on a Recore sits behind one hub connected to it. USB 2.0 reserves bandwidth for cameras up front, when the stream starts, and the total is fixed.

Measured with three MJPEG cameras:

{| class="wikitable"
! Configuration !! Result
|-
| 3 cameras @ 640x480 || '''all three work''' - 27, 20 and 30 fps
|-
| 3 cameras @ 1280x720 || only the first starts; other two fail immediately
|-
| 2 cameras @ 1280x720 || both work - 53 and 30 fps
|-
| 2 cameras @ 1920x1080 || first works, second fails
|}

Bandwidth is claimed on a first-come basis. Whichever camera starts first gets what it asks for, and later cameras get whatever is left - which may be nothing.

=== The signature of running out of bandwidth ===

<pre>
$ dmesg | grep URB
uvcvideo 1-1.3:1.1: Failed to submit URB 0 (-28).
uvcvideo 1-1.1:1.1: Failed to submit URB 0 (-28).
</pre>

<code>-28</code> is <code>ENOSPC</code>. In this context it does not mean disk space - it means the USB controller could not reserve enough bandwidth for the stream.

This failure is '''immediate and unrelated to system load'''. If a camera fails this way it will fail on an idle machine just as reliably. The fix is to lower resolution or frame rate, or to use fewer cameras.

== CPU cost ==

With hardware MJPEG the CPU cost is close to nothing. Three cameras at 640x480, all three being watched in Fluidd:

<pre>
cpu0 9% cpu1 5% cpu2 8% cpu3 6% (softirq 0% on all cores)

ustreamer processes: ~3.6% each, about 11% of one core in total
klipper (python): 7.7% <- more than all three cameras combined
</pre>

Every frame captured reached the browser (<code>queued_fps</code> equalled <code>captured_fps</code> on all three streams), so nothing was being dropped.

A raw YUYV camera changes this picture completely, because ustreamer must then run a software JPEG encoder - it starts four worker threads for a single 640x480 stream.

'''Conclusion:''' on a Recore, multiple cameras are limited by USB bandwidth, not by the processor. Three cameras left the SoC around 90% idle.

== Low frame rate from a single camera ==

If one camera runs far below its rated frame rate, the cause is usually '''exposure time''', not bandwidth.

In dim light a camera on automatic exposure will lengthen its exposure, and exposure time puts a hard ceiling on frame rate: 140 ms per frame is at most 7 fps, no matter what else is configured.

Measured on a Vimicro camera at 640x480:

{| class="wikitable"
! Setting !! Frame rate
|-
| auto exposure (default) || 7.2 fps
|-
| <code>exposure_time_absolute=100</code> (~10 ms) || 19.9 fps
|-
| <code>exposure_time_absolute=30</code> (~3 ms) || 30.0 fps
|}

Note the trade-off: shorter exposure means a darker image. More light on the subject is the better fix where possible.

'''The diagnostic that distinguishes the two causes:''' lower the resolution and re-measure.
* Frame rate improves roughly in proportion - the limit was '''bandwidth'''.
* Frame rate does not change - the limit is '''exposure''' (or something else per-frame).

In the case above, 320x240 gave exactly the same 7 fps as 640x480, which ruled out bandwidth before anything was changed.

Setting exposure manually in crowsnest:

<pre>
[cam 1]
v4l2ctl: auto_exposure=1,exposure_time_absolute=100
</pre>

== Configuration ==

=== Use stable device paths ===

Do '''not''' use <code>/dev/video0</code>, <code>/dev/video2</code> and so on in configuration. These numbers change whenever a camera is added, removed or replugged - on the test board <code>/dev/webcam</code> moved from <code>video2</code> to <code>video5</code> to <code>video7</code> in a single afternoon as cameras were swapped, silently changing which camera was being streamed.

Use the by-id path instead:

<pre>
$ ls /dev/v4l/by-id/
usb-046d_Logitech_BRIO_E76A9283-video-index0
usb-Sonix_Technology_Co.__Ltd._AUKEY_PC-W1_SN0001-video-index0
</pre>

<code>index0</code> matters: a UVC camera exposes several device nodes and only the first is the capture device. The BRIO exposes four; the rest carry metadata.

=== Example crowsnest configuration ===

Three cameras, all MJPEG, at a resolution where all three fit:

<pre>
[crowsnest]
log_level: verbose
rollover_on_start: false
no_proxy: false

[cam 1]
mode: ustreamer
port: 8080
device: /dev/v4l/by-id/usb-046d_Logitech_BRIO_E76A9283-video-index0
resolution: 640x480
max_fps: 30
custom_flags: --format=MJPEG --drop-same-frames=30

[cam 2]
mode: ustreamer
port: 8081
device: /dev/v4l/by-id/usb-Sonix_Technology_Co.__Ltd._AUKEY_PC-W1_SN0001-video-index0
resolution: 640x480
max_fps: 30
custom_flags: --format=MJPEG --drop-same-frames=30

[cam 3]
mode: ustreamer
port: 8082
device: /dev/v4l/by-id/usb-Linux_Foundation_Webcam_gadget-video-index0
resolution: 640x480
max_fps: 30
custom_flags: --format=MJPEG --drop-same-frames=30
</pre>

Ports map to URLs: 8080 is <code>/webcam/</code>, 8081 is <code>/webcam2/</code>, 8082 is <code>/webcam3/</code>.

=== Adding cameras to Fluidd ===

Each camera has to be registered in Moonraker before it appears in the interface. In Fluidd: '''Settings -> Camera -> Add Camera''', then set the stream URL to <code>/webcam2/?action=stream</code> and the snapshot URL to <code>/webcam2/?action=snapshot</code>.

Choose service '''"MJPEG Stream"''' rather than '''"MJPEG Stream (Adaptive)"'''. In adaptive mode the browser fetches individual snapshots at its own pace instead of consuming the stream, and it throttles to <code>target_fps_idle</code> - 5 fps by default - whenever the printer is not printing. A camera capturing at 20 fps can appear to run at 2 fps for this reason alone, with nothing wrong on the Recore at all.

== Troubleshooting ==

{| class="wikitable"
! Symptom !! Likely cause !! Check
|-
| Second or third camera never starts || USB bandwidth || <code>dmesg | grep URB</code> for <code>-28</code>
|-
| Low fps, unchanged by lowering resolution || exposure time || <code>v4l2-ctl -d /dev/webcam --list-ctrls</code>
|-
| Low fps, improves when resolution is lowered || USB bandwidth || reduce resolution or camera count
|-
| Fluidd shows ~2-5 fps, board reports more || Fluidd adaptive mode || set service to plain "MJPEG Stream"
|-
| High CPU from ustreamer || camera has no MJPEG || <code>v4l2-ctl --list-formats-ext</code>
|-
| Camera works, then stops after replug || device path changed || use <code>/dev/v4l/by-id/</code>
|-
| All cameras stop after adding one || crowsnest crash - see below || <code>journalctl -u crowsnest</code>
|}

=== Useful commands ===

<pre>
# What formats and frame rates does this camera support?
v4l2-ctl --list-formats-ext -d /dev/video2

# What controls does it have (exposure, brightness, ...)?
v4l2-ctl --list-ctrls -d /dev/video2

# What is the stream actually doing right now?
curl -s http://localhost:8080/state

# Which USB devices are attached, and at what speed?
for d in /sys/bus/usb/devices/[0-9]*-[0-9]*; do
echo "$(basename $d) $(cat $d/speed)M $(cat $d/product 2>/dev/null)"
done
</pre>

The <code>/state</code> endpoint is the quickest way to see what is happening:

<pre>
"encoder": {"type": "HW"} <- hardware MJPEG, no CPU cost
"encoder": {"type": "CPU"} <- software encoding, camera has no MJPEG
"online": false <- camera not delivering frames at all
"captured_fps": 27 <- what the camera produces
"queued_fps": 27 <- what reaches viewers; lower means drops
</pre>

=== Known issue: one camera can prevent all others from starting ===

Crowsnest v5.0.11 crashes on startup if any attached camera exposes a V4L2 control without a <code>default</code> value, which is legal and occurs on some cameras:

<pre>
File "crowsnest/camera/types/uvc.py", line 72, in get_controls_string
line += f" default={data['default']}"
KeyError: 'default'
</pre>

The crash happens before '''any''' camera starts, so a single unusual camera takes down every stream on the machine. Changing the log level does not avoid it, because the controls are enumerated regardless.

Workaround, until fixed upstream - in <code>crowsnest/camera/types/uvc.py</code>:

<pre>
line += f" default={data.get('default', 'n/a')}"
</pre>

== Background: why the USB bus is the limit ==

The Allwinner A64 has one EHCI host controller. Every USB device on a Recore - cameras, WiFi dongles, USB storage, USB serial - shares it.

USB 2.0 gives cameras ''isochronous'' transfers: guaranteed, reserved bandwidth, claimed when the stream opens. The specification caps this at 80% of the bus, and the reservation is made up front based on the requested resolution and frame rate. This is why a camera either starts successfully or fails immediately, rather than degrading gradually.

It was previously suspected that USB interrupt handling on a single CPU core was the constraint. Measurement does not support this for cameras:

<pre>
$ grep ehci /proc/interrupts
57: 429 992573 0 0 GICv2 106 Level ehci_hcd:usb1
cpu0 cpu1
</pre>

The interrupt is handled on one core, but with three cameras streaming to three viewers that core was only 5% busy, and softirq time was zero across all cores.

'''However''', high single-core load ''has'' been measured on Recore when networking runs over a '''USB WiFi dongle''' - 73% of one core to receive 1.2 MB/s. In that case the USB completion handling and the entire network stack land on the same core. Cameras over Ethernet do not have this problem, because Ethernet on the A64 is a separate peripheral that does not use USB at all.

So: '''a Recore with cameras and a USB WiFi dongle is a meaningfully heavier configuration than one using Ethernet.''' If cameras behave badly over WiFi but well over Ethernet, this is why.

== H.264 and HEVC ==

Some cameras offer H.264 or HEVC in addition to MJPEG. These are '''far''' more efficient than MJPEG, but they '''cannot currently be used on Recore'''. This section records why, so the question does not need re-investigating.

=== The efficiency is dramatic ===

Measured on a 4K microscope camera, same board, same bus, 45 frames per run:

{| class="wikitable"
! Format !! Resolution !! Frame rate !! Per frame
|-
| MJPEG || 1920x1080 || 29.9 fps || 395 kB
|-
| '''H.264''' || 1920x1080 || 29.8 fps || '''18 kB''' (22x smaller)
|-
| H.264 || 3840x2160 || 26.3 fps || 89 kB
|-
| '''HEVC''' || 3840x2160 || '''30.0 fps''' || '''73 kB''' (25x smaller)
|-
| MJPEG || 3840x2160 || 12.7 fps || 1871 kB
|}

'''4K HEVC at a full 30 fps uses about five times less bandwidth than 1080p MJPEG.''' Note also that MJPEG at 4K cannot reach 30 fps at all - it manages 12.7 fps because it saturates the USB bus, while HEVC at the same resolution runs at the full rate.

If these codecs worked, the bandwidth limits described above would largely disappear.

=== Why it does not work ===

The blocker is '''camera-streamer''', not crowsnest and not ustreamer.

* '''ustreamer''' handles MJPEG only, by design. It is not the limitation, because crowsnest can launch camera-streamer instead.
* '''camera-streamer''' does support H.264 and captures it correctly - it negotiates <code>1920x1080/H264</code> without trouble - but it then fails to start:

<pre>
device/buffer_list.c: CAMERA:capture: Using: 1920x1080/H264, buffers=3 <- capture works
device/camera/camera_decoder.c: CAMERA: Cannot find 'H264' decoder
device/camera/camera_output.c: CAMERA: Cannot find source for 'SNAPSHOT' for one of the formats 'JPEG, MJPG'.
</pre>

Two things combine to make this a hard stop:

'''1. The snapshot output cannot be disabled.''' camera-streamer 0.4.2.4 provides <code>--camera-stream.disabled</code> and <code>--camera-video.disabled</code>, but there is no equivalent for snapshot. Snapshot must be JPEG or MJPG, so H.264 input has to be decoded to satisfy it. Disabling the other two outputs does not help - it still exits.

'''2. The A64's video decoder is the wrong kind.''' The SoC does have a hardware decoder (<code>cedrus</code>), and it does handle H.264 and HEVC, but note the formats it accepts:

<pre>
$ v4l2-ctl -d /dev/video0 --list-formats-out
[1]: 'S264' (H.264 Parsed Slice Data, compressed)
[2]: 'S265' (HEVC Parsed Slice Data, compressed)
</pre>

"Parsed Slice Data" means this is a '''stateless''' decoder. Userspace has to parse the bitstream itself, extract the sequence and picture parameter sets, and drive the hardware slice by slice through the Media Request API. camera-streamer expects a '''stateful''' decoder - the kind found on the Raspberry Pi, where a stream goes in and frames come out. These are fundamentally different programming models, so camera-streamer cannot use cedrus even though the hardware is capable.

This is not a missing driver, a missing package or a configuration mistake.

=== What would be needed ===

* '''Patch camera-streamer''' to allow the snapshot output to be disabled, then pass H.264 through to WebRTC without decoding at all. This is the smallest change and would deliver the bandwidth saving. The drawback is that WebRTC is the only viable output - Fluidd displays cameras with an ordinary image element, which cannot show H.264.
* '''Use a decoder that speaks stateless V4L2''' - ffmpeg with the Request API, or libva - to convert H.264 to MJPEG on the board. This keeps compatibility with existing interfaces, but re-introduces a per-frame cost, which is much of what the codec was meant to avoid.

Until one of those exists, '''use MJPEG''', and treat a camera's H.264 or HEVC support as a bonus that is not currently usable. A camera offering H.264 will almost always offer MJPEG too, so such cameras are still fine to buy.

== See also ==

* [https://github.com/intelligent-agent/Rebuild/issues/76 Rebuild issue #76] - USB interrupt handling and multi-camera investigation, with measurements
* [https://docs.mainsail.xyz/crowsnest/ Crowsnest documentation]

2026-06-04T20:42:56Z

Elias: /* Schematics */

Reheat is a 6 output heater board with temperature sensors and fans for multi material printing.
<div class="res-img">
[[File:Reheat A0.png]]
</div>

==Schematics==
* [https://github.com/intelligent-agent/Recore/blob/master/Schematics/Reheat_A0.pdf Reheat A0 Schematics (PDF)]
==Config tool==
* [https://config.iagent.no/ Reheat A0 config tool]

==Features==
* RP2354B microcontroller (ARM Cortex-M33, 150 MHz)
* 6x heater outputs (24 V, MOSFET-switched)
* 6x fan outputs (24 V PWM) with tachometer inputs
* 6x thermistor/temperature sensor inputs
** Supports: NTC 10K, NTC 100K, PT100, PT1000, Type K thermocouple
** Jumper-selectable per channel
* 12x endstop inputs (5 V tolerant, TVS-protected)
** ENDSTOP-12 supports a bidirectional signal (e.g. filament encoder)
* USB-C interface (USB 2.0)
* 24 V power input with onboard 5 V (3 A) and 3.3 V regulation
* Overcurrent detection on fan bus

==Pinout==

{| class="wikitable"
|-
! GPIO !! Signal !! Connector
|-
| GPIO0 || HEATER-1 || J2
|-
| GPIO1 || HEATER-2 || J3
|-
| GPIO2 || HEATER-3 || J6
|-
| GPIO3 || HEATER-4 || J11
|-
| GPIO4 || HEATER-5 || J12
|-
| GPIO5 || HEATER-6 || J13
|-
| GPIO6 || FAN-1 || J34
|-
| GPIO7 || FAN-2 || J35
|-
| GPIO8 || FAN-3 || J36
|-
| GPIO9 || FAN-4 || J37
|-
| GPIO10 || FAN-5 || J38
|-
| GPIO11 || FAN-6 || J39
|-
| GPIO12 || TACH-1 || J34
|-
| GPIO13 || TACH-2 || J35
|-
| GPIO14 || TACH-3 || J36
|-
| GPIO15 || TACH-4 || J37
|-
| GPIO16 || TACH-5 || J38
|-
| GPIO17 || TACH-6 || J39
|-
| GPIO18 || ENDSTOP-1 || J14
|-
| GPIO19 || ENDSTOP-2 || J15
|-
| GPIO20 || ENDSTOP-3 || J16
|-
| GPIO21 || ENDSTOP-4 || J17
|-
| GPIO22 || ENDSTOP-5 || J18
|-
| GPIO23 || ENDSTOP-6 || J19
|-
| GPIO24 || ENDSTOP-7 || J20
|-
| GPIO25 || ENDSTOP-8 || J21
|-
| GPIO26 || ENDSTOP-9 || J22
|-
| GPIO27 || ENDSTOP-10 || J23
|-
| GPIO28 || ENDSTOP-11 || J24
|-
| GPIO29 || ENDSTOP-12 || J25
|-
| GPIO30 || MUX-S0 || Internal
|-
| GPIO31 || MUX-S1 || Internal
|-
| GPIO32 || MUX-S2 || Internal
|-
| GPIO33 || PWM-GAIN || Internal
|-
| GPIO34 || PWM-OFFSET || Internal
|-
| GPIO35 || PWM-CURRENT || Internal
|-
| GPIO36 || EN-PULLUP || Internal
|-
| GPIO37 || ENDSTOP-12-DIR || J25
|-
| GPIO38 || FAN-OC (overcurrent) || Internal
|-
| GPIO40 / ADC0 || THERM-1 || J27
|-
| GPIO41 / ADC1 || THERM-2 || J28
|-
| GPIO42 / ADC2 || THERM-3 || J29
|-
| GPIO43 / ADC3 || THERM-4 || J30
|-
| GPIO44 / ADC4 || THERM-5 || J31
|-
| GPIO45 / ADC5 || THERM-6 || J32
|-
| GPIO46 / ADC6 || ADC (MUX output) || Internal
|-
| GPIO47 / ADC7 || CURRENT sense || Internal
|}

==Hardware connections==

===Power===
The board takes 24 V DC on a 4-pin connector (J33). A fuse (F1) and a 2 mΩ current-sense resistor (R98) protect the input. Onboard regulators provide +5 V (TPS54302 buck converter, 3 A) and +3.3 V (AMS1117-3.3, 1 A) for logic and sensor pull-ups.

===Heaters===
Six heater outputs use 2SK3019 N-channel MOSFETs driven from GPIO0–GPIO5. Each output has a 2-pin female connector and a flyback Schottky diode. The heater voltage is 24 V.

===Fans===
Six fan outputs (GPIO6–GPIO11) use N-channel MOSFETs with a 24 V supply. Each has a 3-pin connector (V+, GND, TACH). Tachometer signals are read on GPIO12–GPIO17. An LM393 comparator monitors the fan bus for overcurrent and signals FAN-OC on GPIO38.

===Thermistors===
Each thermistor channel has a 3-pin connector (J27–J32) with a jumper (JP1–JP6) to select the measurement mode. An analog MUX (CD4051) and op-amp signal conditioning chain feed the ADC inputs (GPIO40–GPIO45). The signal conditioning supports:

{| class="wikitable"
|-
! Sensor type !! Measurement method
|-
| NTC 10K || Voltage divider with 4.7 K pull-up
|-
| NTC 100K || Voltage divider with 4.7 K pull-up
|-
| PT100 || 1 mA constant current source (Kelvin connection)
|-
| PT1000 || 1 mA constant current source (Kelvin connection)
|-
| Type K thermocouple || ×101 gain amplifier, buffered
|}

For NTC thermistor or PT1000 measurements, close jumpers JP1–JP6 to connect the 4.7 K pull-up resistors. With the jumpers closed, ADC0–ADC5 (GPIO40–GPIO45) can be used as standard thermistor inputs with a 4.7 K pull-up to 3.3 V, without the need for any additional signal conditioning.

==Errata==
# DP/DM USB data lines are swapped.
# RUN pin is hardwired to ground, preventing software reset.
# U11 and U15 (LMV321 op-amps in thermistor circuit) have V+ and V- supply pins reversed.
# Pull-up resistor footprints (JP1–JP6) use a 1 mm pin pitch instead of the standard 2.54 mm.
# VUSB is unconnected, so the board requires 24 V power to operate even when connected over USB.

==Klipper configuration==

The Reheat A0 connects to the host over USB and is configured as an MCU in Klipper. Find the serial path with <code>ls /dev/serial/by-id/</code> and add to <code>printer.cfg</code>:

<pre>
[mcu reheat]
serial: /dev/serial/by-id/usb-Klipper_rp2350_XXXXXXXXXXXX-if00
</pre>

===Heaters===
<pre>
[heater_generic heater1]
heater_pin: reheat:gpio0
sensor_type: NTC 100K MGB18-104F39050L32
sensor_pin: reheat:gpio40
control: pid
pid_Kp: 22
pid_Ki: 1.08
pid_Kd: 114

[heater_generic heater2]
heater_pin: reheat:gpio1
sensor_type: NTC 100K MGB18-104F39050L32
sensor_pin: reheat:gpio41
control: pid
pid_Kp: 22
pid_Ki: 1.08
pid_Kd: 114
</pre>

===Fans===
<pre>
[fan_generic fan1]
pin: reheat:gpio6

[fan_generic fan2]
pin: reheat:gpio7
</pre>

===Endstops===
Endstop pins can be referenced in the relevant stepper sections:
<pre>
[stepper_x]
endstop_pin: reheat:gpio18
</pre>

==Flashing Klipper==

# Put the board in BOOTSEL mode: hold the BOOT button while plugging in USB (or hold BOOT, press RESET, then release BOOT).
# Build and flash from the Klipper source directory:
<pre>
make menuconfig
# Processor model: rp2350
# Bootloader offset: No bootloader
# Communication interface: USBSERIAL
make
picotool load out/klipper.uf2 --force
picotool reboot
</pre>
The board will reboot and appear as <code>/dev/ttyACM0</code> (or similar).

==Full config file==
<pre>
# ======================================================================
# Reheat_A0.cfg — Complete Klipper configuration for the Reheat A0
# MCU: RP2354B (RP2350 family, ARM Cortex-M33, 150 MHz, 48 GPIO, 8 ADC)
# Source: https://wiki.iagent.no/wiki/Reheat_A0
#
# Board functions:
# 6x heater outputs (24V MOSFET) GPIO0..GPIO5
# 6x fan outputs (24V PWM) GPIO6..GPIO11
# 6x fan tachometer inputs GPIO12..GPIO17
# 12x endstop inputs (5V tolerant) GPIO18..GPIO29 (+ GPIO37 dir)
# 6x thermistor/temperature ADC inputs GPIO40..GPIO45 (ADC0..ADC5)
# analog mux + PWM bias control GPIO30..GPIO35
# endstop pull-up enable GPIO36
# fan over-current flag GPIO38
# ADC mux output / input-current sense GPIO46/GPIO47 (ADC6/ADC7)
#
# Each fan is paired with its matching heater (FAN1<->HEATER1, ...).
#
# Build firmware: RP2350 (ARM) processor, USB communication.
# Flash: hold BOOT while plugging in USB-C to enter BOOTSEL.
# ERRATA: RUN pin is hardwired -> Klipper cannot software-reset the MCU
# (re-enter BOOTSEL manually to reflash). USB DP/DM are swapped.
# ======================================================================

# ----------------------------------------------------------------------
# MCU
# ----------------------------------------------------------------------
[mcu reheat]
# USB-C, enumerates over USB. Use the stable by-id path:
# ls /dev/serial/by-id/*
serial: /dev/serial/by-id/usb-Klipper_rp2350_21745F8FD0431B3A-if00
restart_method: command

# ----------------------------------------------------------------------
# Endstop pull-up enable (GPIO36)
# Drive high at boot so the 12 endstop inputs read correctly.
# ----------------------------------------------------------------------
[static_digital_output endstop_pullup_enable]
pins: reheat:gpio36

# ======================================================================
# HEATERS (24V MOSFET outputs, paired with ADC thermistors)
# Sensor types supported by the board: NTC 10K, NTC 100K, PT100,
# PT1000, Type-K thermocouple. NTC 100K -> "Generic 3950".
# Pairing of heater<->thermistor is arbitrary; reassign as needed.
# ======================================================================

[heater_generic heater1] # HEATER1 / THERM1
heater_pin: reheat:gpio0
sensor_pin: reheat:gpio40 # ADC0
sensor_type: EPCOS 100K B57560G104F
control: pid
pid_Kp: 22
pid_Ki: 1.08
pid_Kd: 114
min_temp: -272
max_temp: 300

[heater_generic heater2] # HEATER2 / THERM2
heater_pin: reheat:gpio1
sensor_pin: reheat:gpio41 # ADC1
sensor_type: EPCOS 100K B57560G104F
control: pid
pid_Kp: 22
pid_Ki: 1.08
pid_Kd: 114
min_temp: -272
max_temp: 300

[heater_generic heater3] # HEATER3 / THERM3
heater_pin: reheat:gpio2
sensor_pin: reheat:gpio42 # ADC2
sensor_type: EPCOS 100K B57560G104F
control: watermark
min_temp: -272
max_temp: 300

[heater_generic heater4] # HEATER4 / THERM4
heater_pin: reheat:gpio3
sensor_pin: reheat:gpio43 # ADC3
sensor_type: EPCOS 100K B57560G104F
control: watermark
min_temp: -272
max_temp: 300

[heater_generic heater5] # HEATER5 / THERM5
heater_pin: reheat:gpio4
sensor_pin: reheat:gpio44 # ADC4
sensor_type: EPCOS 100K B57560G104F
control: watermark
min_temp: -272
max_temp: 300

[heater_generic heater6] # HEATER6 / THERM6
heater_pin: reheat:gpio5
sensor_pin: reheat:gpio45 # ADC5
sensor_type: EPCOS 100K B57560G104F
control: watermark
min_temp: -272
max_temp: 300

# ======================================================================
# FANS (24V PWM)
# Each fan follows its matching heater (FAN1<->HEATER1, FAN2<->HEATER2,
# ... FAN6<->HEATER6) and turns on when that heater is active.
# ======================================================================

[heater_fan fan1] # FAN1 -> HEATER1
pin: reheat:gpio6
heater: heater1
heater_temp: 50.0

[heater_fan fan2] # FAN2 -> HEATER2
pin: reheat:gpio7
heater: heater2
heater_temp: 50.0

[heater_fan fan3] # FAN3 -> HEATER3
pin: reheat:gpio8
heater: heater3
heater_temp: 50.0

[heater_fan fan4] # FAN4 -> HEATER4
pin: reheat:gpio9
heater: heater4
heater_temp: 50.0

[heater_fan fan5] # FAN5 -> HEATER5
pin: reheat:gpio10
heater: heater5
heater_temp: 50.0

[heater_fan fan6] # FAN6 -> HEATER6
pin: reheat:gpio11
heater: heater6
heater_temp: 50.0

# ======================================================================
# ENDSTOPS (11 inputs, 5V tolerant) + NeoPixel on EP12
# This board has no stepper drivers, so endstops are exposed as
# runtime-readable buttons. To use one as a homing endstop instead,
# reference its pin from a stepper on your motion board, e.g.:
# [stepper_x]
# endstop_pin: reheat:gpio18
# Endstop 12 (GPIO29) is wired to a NeoPixel data line (see below).
# ======================================================================

# Each endstop is exposed as a button so its state is queryable. The
# press/release gcode is intentionally empty (just reads the input).
[gcode_button endstop1]
pin: reheat:gpio18
press_gcode:
release_gcode:

[gcode_button endstop2]
pin: reheat:gpio19
press_gcode:
release_gcode:

[gcode_button endstop3]
pin: reheat:gpio20
press_gcode:
release_gcode:

[gcode_button endstop4]
pin: reheat:gpio21
press_gcode:
release_gcode:

[gcode_button endstop5]
pin: reheat:gpio22
press_gcode:
release_gcode:

[gcode_button endstop6]
pin: reheat:gpio23
press_gcode:
release_gcode:

[gcode_button endstop7]
pin: reheat:gpio24
press_gcode:
release_gcode:

[gcode_button endstop8]
pin: reheat:gpio25
press_gcode:
release_gcode:

[gcode_button endstop9]
pin: reheat:gpio26
press_gcode:
release_gcode:

[gcode_button endstop10]
pin: reheat:gpio27
press_gcode:
release_gcode:

[gcode_button endstop11]
pin: reheat:gpio28
press_gcode:
release_gcode:

# NeoPixel on the EP12 connector (GPIO29 data line).
[neopixel reheat_led]
pin: reheat:gpio29
chain_count: 1
color_order: GRB
initial_RED: 0.0
initial_GREEN: 0.0
initial_BLUE: 0.0

# EP12 direction line (GPIO37) — drive the level-shifter towards the
# NeoPixel (output direction).
[static_digital_output endstop12_dir]
pins: reheat:gpio37

# ======================================================================
# ANALOG MUX + PWM BIAS (board-internal sensor front-end)
# MUX_S0..S2 select one of the multiplexed analog channels, read back
# on ADC_MUX (GPIO46/ADC6). PWM_GAIN/OFFSET/CURRENT set the analog
# amplifier bias used for PT100/thermocouple measurement.
# These are exposed as raw pins; exact scaling is board-specific.
# ======================================================================

[output_pin mux_s0]
pin: reheat:gpio30

[output_pin mux_s1]
pin: reheat:gpio31

[output_pin mux_s2]
pin: reheat:gpio32

[output_pin pwm_gain]
pin: reheat:gpio33
pwm: True
cycle_time: 0.001
value: 0

[output_pin pwm_offset]
pin: reheat:gpio34
pwm: True
cycle_time: 0.001
value: 0

[output_pin pwm_current]
pin: reheat:gpio35
pwm: True
cycle_time: 0.001
value: 0

# ======================================================================
# PROTECTION / MONITORING
# ======================================================================

# Fan over-current flag (GPIO38) — reads active on an over-current event.
[gcode_button fan_overcurrent]
pin: reheat:gpio38
press_gcode:
release_gcode:

# Input-current sense (GPIO47 / ADC7) via the 2 mΩ shunt.
# Scale: 1 A = 0.1 V -> 3.3 V full-scale = 33 A. The reported
# "temperature" value is therefore the input current in amps.
[adc_temperature reheat_current]
temperature1: 0
voltage1: 0
temperature2: 33
voltage2: 3.3

[temperature_sensor input_current]
adc_voltage: 3.3
sensor_pin: reheat:gpio47
sensor_type: reheat_current
min_temp: -1
max_temp: 40

</pre>

[[Category:Hardware]]

==Errata==
# DP/DM USB data lines are swapped.
# RUN pin is hardwired to ground, preventing software reset.
# U11 and U15 (LMV321 op-amps in thermistor circuit) have V+ and V- supply pins reversed.
# Pull-up resistor footprints (JP1–JP6) use a 1 mm pin pitch instead of the standard 2.54 mm.

Reheat A0

2026-06-04T17:57:01Z