<p>According to <a href="https://marlinfw.org/docs/configuration/configuration.html#baud-rate" rel="nofollow noreferrer">Marlin docs</a>, these checksum mismatch errors were due to the baud rate being set incorrectly.</p>
<blockquote>
<p>The serial communication speed of the printer should be as fast as it can manage without generating errors. In most cases 115200 gives a good balance between speed and stability. Start with 250000 and only go lower if “line number” and “checksum” errors start to appear.</p>
</blockquote>
<p>Lowering baud rate solved the problem.</p>

CC BY-SA 4.0
2022-12-23T09:36:37.343Z
2022-12-23T09:36:37.343Z
kosteklvp
<p>Recently, I've installed a new BIGTREETECH SKR mini E3 V3.0 board on Creality Ender-5. Previously, I was using SKR mini E3 V1.2 board, but it broke down and I had to replace it. I connected new one exactly like the previous board and calibrated the printer. Everything seemed to be working properly.</p>
<p>Now, I'm getting unexpected <code>M122</code> errors while printing from OctoPrint:</p>
<p><a href="https://i.sstatic.net/CRGHS.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/CRGHS.jpg" alt="M122 error on printer's display" /></a></p>
<p>This is OctoPrint's console output:</p>
<pre><code>Recv: ok
Recv: Error:checksum mismatch, Last Line: 30869
Recv: Resend: 30870
Should resend line 30870 but no sufficient history is available, can't resend
Changing monitoring state from &quot;Printing&quot; to &quot;Error&quot;
Send: G1 X109.711 Y118.883 E.02691
Send: M112
Send: N31035 M112*37
Send: N31036 M104 T0 S0*38
Send: N31037 M140 S0*99
Changing monitoring state from &quot;Error&quot; to &quot;Offline after error&quot;
Connection closed, closing down monitor
Closing down send loop
</code></pre>
<p>This checksum mismatch error appears randomly at different stages of printing, but always around 30000 line.</p>
<hr />
<p><strong>What is my setup?</strong></p>
<ul>
<li>Creality Ender-5</li>
<li>Raspberry Pi 3A+</li>
<li>OctoPrint 1.8.6</li>
<li>OctoPi 0.18.0</li>
<li>SKR mini E3 V3.0 board</li>
<li><a href="https://github.com/kosteklvp/Marlin-SKR-mini-E3-v3/tree/209c69f887105b52191fd1c229e103a0a27b5862/Marlin" rel="nofollow noreferrer">My custom firmware</a></li>
</ul>
<p>I customized the firmware from BIGTREETECH official repository for this board. This problem also occurs, when I upload official firmware for this board. OctoPrint is connected to the board via GPIO pins - that's how it was connected before and I have no way to connect it via USB cable.</p>
<hr />
<p><strong>What have I done to resolve this issue?</strong></p>
<ul>
<li>Tried printing from SD card. This error doesn't occur, when printing from SD card.</li>
<li>Replaced cables connecting the board with Raspberry Pi.</li>
<li>Isolated all the electronics away from the printer's case.</li>
<li>Changed SD card used by OctoPrint to a new, empty one.</li>
<li>Updated OctoPrint to recent, stable version.</li>
<li>Uninstalled all unnecessary OctoPrint plugins.</li>
<li>Tried flashing official firmware.</li>
</ul>
<p>I suppose that the problem is in the connection between the printer and OctoPrint. What can cause this error to happen?</p>

<octoprint><skr-mini-e3><serial-connection>
What causes checksum mismatch error while printing from OctoPrint?
kosteklvp
# What causes checksum mismatch error while printing from OctoPrint?

(Asked by: username_0 on 2022-12-21)

Recently, I've installed a new BIGTREETECH SKR mini E3 V3.0 board on Creality Ender-5. Previously, I was using SKR mini E3 V1.2 board, but it broke down and I had to replace it. I connected new one exactly like the previous board and calibrated the printer. Everything seemed to be working properly.

Now, I'm getting unexpected `M122` errors while printing from OctoPrint:

[![M122 error on printer's display](https://i.sstatic.net/CRGHS.jpg)](https://i.sstatic.net/CRGHS.jpg)

This is OctoPrint's console output:

```
Recv: ok
Recv: Error:checksum mismatch, Last Line: 30869
Recv: Resend: 30870
Should resend line 30870 but no sufficient history is available, can't resend
Changing monitoring state from "Printing" to "Error"
Send: G1 X109.711 Y118.883 E.02691
Send: M112
Send: N31035 M112*37
Send: N31036 M104 T0 S0*38
Send: N31037 M140 S0*99
Changing monitoring state from "Error" to "Offline after error"
Connection closed, closing down monitor
Closing down send loop

```

This checksum mismatch error appears randomly at different stages of printing, but always around 30000 line.

---

**What is my setup?**

* Creality Ender-5
* Raspberry Pi 3A+
* OctoPrint 1.8.6
* OctoPi 0.18.0
* SKR mini E3 V3.0 board
* [My custom firmware](https://github.com/username_0/Marlin-SKR-mini-E3-v3/tree/209c69f887105b52191fd1c229e103a0a27b5862/Marlin)

I customized the firmware from BIGTREETECH official repository for this board. This problem also occurs, when I upload official firmware for this board. OctoPrint is connected to the board via GPIO pins - that's how it was connected before and I have no way to connect it via USB cable.

---

**What have I done to resolve this issue?**

* Tried printing from SD card. This error doesn't occur, when printing from SD card.
* Replaced cables connecting the board with Raspberry Pi.
* Isolated all the electronics away from the printer's case.
* Changed SD card used by OctoPrint to a new, empty one.
* Updated OctoPrint to recent, stable version.
* Uninstalled all unnecessary OctoPrint plugins.
* Tried flashing official firmware.

I suppose that the problem is in the connection between the printer and OctoPrint. What can cause this error to happen?

**Tags:** octoprint, skr-mini-e3, serial-connection


---

## 1 answers

### Answer by username_0 on 2022-12-23. Score: 1 | Accepted answer

According to [Marlin docs](https://marlinfw.org/docs/configuration/configuration.html#baud-rate), these checksum mismatch errors were due to the baud rate being set incorrectly.

> The serial communication speed of the printer should be as fast as it can manage without generating errors. In most cases 115200 gives a good balance between speed and stability. Start with 250000 and only go lower if “line number” and “checksum” errors start to appear.

Lowering baud rate solved the problem.


---

