But you might want to read this issue though. It's about the non-standard responses from your firmware.
I never use the SD card on the printer but have tried with two different cards in situ and also with nothing inserted just to see. I have two Pi units, two Pi original power supplies and several cables. No joy there either.
The missing 1 in the N4 line is bizarre. When I display the file in Notepad++ I get N4 MBEL05*35 with the symbol BEL given a black background. You have the same file showing an "a". Probably just a language thing. BEL is ASCII 7.
In order to remove all problems, if any, caused by the Raspberry Pi I have just spent the best part of an hour installing OctoPrint on a Windows 10 machine connected through USB to the printer directly. The problem is exactly the same. Failure in line 4.
Just to make sure: Have you in fact also installed the two plugins indicated in the aforementioned issue?
Yes. Both installed.
Please create a new serial.log of the current state. That will tell us more of the whole story than just the excerpts dumped into octoprint.log on resend requests. I'm note sure if the last one from December still reflects the current state or not.
In any case, this is on your printer's firmware and I suggest you also complain to your printer's manufacturer about this issue, they might be able to actually do something about it, all we can do here is suggest workarounds like the aforementioned plugins.
Also maybe try a different USB cable between OctoPrint and your printer, because from the looks of what the printer does send back it's certainly not receiving what OctoPrint is sending and that reeks of communication errors due to cabling errors and/or undervoltage (of which I don't see any hints in your logs though). Could also be that your printer's board simply has a fault.
octoprint (1).log (182.9 KB)
As requested, the log file. I have tried to contact Tronxy but they are on holiday for the chinese new year. They never reply anyway. I have tried many cables already and from three computers. The printer will only function with a file on it's own SD card.
I have just ordered one of your premium hoodies to see if that makes a difference !
serial.log 
Not octoprint.log
Enable serial.log through Settings > Communication first, reproduce the issue, then upload the result.
Yeah, the core of the issue definitely is that your printer is not receiving what OctoPrint is sending. For example, it receives N0 M\x0310*35 instead of N0 M110*35 and then rightfully complains about the checksum mismatch for that. Something is going really wrong in the printer communication, so swap the USB cable, make sure it's shielded, has a ferrite bead, does not run next to motor wires. Also try if you run into similar issues when connecting from a different computer to your printer using Pronterface. And finally get in touch with Tronxy on this, it might also be a broken controller board.
BEL 0x07 looks like 00000111 in binary. (It activated the bell on the original Teletypewriter that would alert the operator at the other end.)
Zero 0x31 looks like 00110001 in binary.
So this doesn't seem to be a single bit getting accidentally toggled in the transmission.
As suggested though, you first have to sort out the trashy serial setup by using a proper cable.
Temporary fix: PrintedWeezl's suggestion of dropping the baud rate would actually help. If you had the ability to adjust the Marlin setup, compile/flash that to the printer you could drop the baud rate down by half until it's happy.
I have tried five cables so far. Some very short indeed. all with ferrites
This printer does not have Marlin but uses a closed version of Repetier.
That's good about the cable(s) but sad about the closed firmware.
You might try temporarily taping the 5V pin of the serial cable as suggested by PrintedWeezl on here. The theory would be that the printer board is sinking so much power from the Pi that it's now corrupting the threshold for high/low determination on the bits.
This doesn't explain why it would have worked before and not now, though, with the same hardware.
Nor why it gives the same result when connected to a Windows computer. I am trying desperately to remember what I did around the time of the upgrade. Did I change anything else ...
I have also ordered another board from Gearbest but with the virus and stuff it may be a long time coming. At least I shall have a second unit to try a Marlin transplant with.
A second printer controller board (with a resistor which pretends that it's a thermistor) is super helpful at a time like this. You power it up, connect it to your OctoPrint setup and send it a print job where you've groomed out the heat/extrusion commands. You're then exercising everything without necessarily wasting filament.
I have tried pronterface now and it does connect and stays connected. I can control movement and temperatures but as soon as I try to print it fails with "callback -pf error" etc..
I shall post more when the second board arrives. Having two boards will enable me to try to install Marlin on one but to retain a fallback system.
Thank you for that but as I said before this board is 32 bit and I am having to use Atom and PlatformIO to do any work on the ChiTu STM32 chip. I did install STM32Flash on the Pi so that Octopi is ready to try a firmware transfer, but since I can't yet connect and I have no file to upload anyway I shall have to wait for that. I am having to learn as I go. Marlin 2.0 for this board is nearly there but if one looks on YouTube, for eaxample, one finds that there are virtually no uploads concerning STM32F103 boards. I suppose everyone is in the same boat as me, waiting for Marlin and playing with the ChiTu boards. There are a few guys working on other makes of printer with 32bit chips and that helps me a lot.
I have found a file of the factory X5SA-400 firmware and will try to backup my X5ST-400 before I start but want to get the second board first. Better safe than sorry.
Finally received the new board which will connect and stay connected with Octoprint 1.4.0. However it seems that the board was delivered with the firmware for an X5SA-400 and not an X5ST-400 and so although it will load a print and raise the temperatures it will not move in the Z-axis. I cannot find the firmware for the ST and there seems to be no way to get Marlin into the machine as yet so I am still stuck.
Have you made any progress with this? here a couple links that might help. https://www.tronxyonline.com/Firmware-X5SA-400-Series-a63179.html
http://www.customize-3d.com/chitu-g-code-explained.html
Thank you for that but no, I have still not managed to print anything after nine months. The best firmware I found had everything working but the Z-stops did not work and the printhead just crashed into the bed.
I now have six different files for the X5SA-400 and three for the ST. None are correct and all are different, giving different failures.
I have downloaded from the page you specify and will try the firmware this morning.
Thanks again.
Martin.