And although it's not been said yet, a Raspberry Pi 3 will do a much better job of running the printer and streaming video than, say, a Raspberry Pi Zero which only has one core.
config.ini, find uart0.baud_rate set to different value, reboot printer if that's smoothieware...
Not smoothieware,, Ender 3 Running Marlin (th3d flavor) printer has no config.ini
EDIT Whats a good baudrate to use if I am going to recompile marlin ?
And although it's not been said yet, a Raspberry Pi 3 will do a much better job of running the printer and streaming video than, say, a Raspberry Pi Zero which only has one core.
This is with a "Raspberry Pi 3 Model B" Going even further using this cable : http://a.co/h0hgMRr with this power supply http://a.co/5YWN6K Although I'm not getting low voltage warnings I did see some negative reviews on that PSU and have another replacement coming today to try..
Appreciate your input,
Just to be pendantic, your cable isn't shielded and yet it's fine for what you're doing given the ferrite core.
Here's an example of one which is and note that the price tag is around four times what you paid for yours. Okay, so it's an HDMI cable but it actually has the word "shielded" in the product's title.
And I note your Raspi 3 response. (Good.) Your power supply link doesn't work, btw.
The absence of low-voltage warnings could be something as simple as your /boot/config.txt configured to not display them: avoid_warnings=1. A better test is to run vcgencmd get_throttled having remoted into the Raspi and try to interpret what you see. You want zero as the output.
From another thread here in which I said:
Running vcgencmd get_throttled should return a variable throttled=0x50005 which ought to be zero if no throttling is occurring (either due to under-voltage or that it's too hot). Following up, a vcgencmd measure_temp (with my own output of temp=41.9'C) will show you if it's looking hot or not which could then rule out temperature.
The low threshold for input power is 4.65VDC, I believe.
So now, back to the issue at hand, I myself recently have been working on a contrived rig and had some problems getting things to work. I had to go all the way down to 9600 baud for it to test okay. But I was watching the terminal responses from my program so that I could see the garbage characters that were coming back from the downstream printer.
pi@octopi:~ vcgencmd get_throttled
throttled=0x0
pi@octopi:~ vcgencmd measure_temp
temp=56.4'C
So its a little warmer than yours but 56 still isn't that bad really I think.. .. Going to try to lower the baud rate down to 9600 later..
1 other thing I just remembered though is I do have a piece of tape over the positive voltage rail on the usb cord connection to the pie so it doesn't backfeed power through my board.. That couldn't possibly cause any issues right ?
So... you're saying that you added some tape inside the Type A end of the USB cord which goes to the Raspi so that the printer doesn't supply power to the Raspi.
If you did it perfectly, then this shouldn't affect you.
If you accidentally also covered either the RXD or TXD pin on that connector then it would behave as you've described.
sorry mate my bad, I was doing something with smoothiware code and replied to your post somehow seeing that you use smoothieware 
... happens ..
the 115200 is already too slow for some precise short moves, if you have a lot of them, so going as fast as possible is always advisable .. the idea to lower down the speed is just to test if that would solve the problem, but it's not really a solution... if you can't have the stable connection between the two I'd go with sdcard printing 
..
now said that, I seen soo many issues wrt PRC made cables (long, short, expensive, cheap...) so using brand name cables actually makes sense... I have rather good experience with ugreen, it's prc made, cheap, but never had any issues with them (does not mean it's 100% safe, main issue with PRC made stuff is quality control so some % of delivered goods will always be faulty) ...
I seen alu tape help (use alu tape, wrap around cable, connect to ground on one side only, so to either printer or to the rpi) but...
I'm not very good with marlin, see with marlin experts if you can somehow debug marlin and see what happens when you lose connection... I'd personally attach a logic analyzer between usb2uar and atmega ... your board, what usb2uart chip it uses? some cheap ch30 or atmel u* chip or ftdi? it can be a faulty chip, it's known to happen ...
It really depends on the board ... I'v seen boards where usb2uart chip does not work reliably if the 5Vusb is not present
I'll try a ugreen cable.. willing to try anything at this point..
I believe the chip is an FTDI (thats what shows in lsusb from the PI) ..
If your cable isn't too long, you can temporarily make a "poor man's shielding"...
- get some aluminum foil
- and some Scotch tape
- cut the aluminum foil in long strips of the same width as the circumference of your serial cable
- put some Scotch tape on the table upside down (securing the ends)
- put the aluminum foil strip on top of the tape so that a 1/4" of the tape isn't covered
- wrap the aluminum foil + tape around the serial cable, aluminum side toward the cable
- stick the tape so that it stays
- wrap it again with tape so that none of the aluminum can short to something else (insulating it)
Then put it back into service. A real version of a shielded cable then connects the ground wire to the shielding but this version is good enough. If you find that this poor man's version allows you to connect to your printer, then go buy an expensive one.
If it's a cheap board, it could be a clone FTDI chip, google "ftdi gate". If you have a clone ftdi chip then, good luck.
that's kinda worse possible scenario ... since afaik ENDER 3 is a CREALITY I seriously doubt that board uses original FTDI chip as @PythonAteMyPerl already suspected ... those chips are so unstable ...
Check the board, see if, maybe, between ftdi chip (the only chip after usb connector) and big atmega chip are some 3 or 4 test pins, maybe even 3-4 pin header? try to follow traces from those pins where they go to ftdi chip or to atmega chip... if those pins are exposed you can bypass the crappy chip and connect uart directly from rpi to atmega
of course, before all that, try a decent usb cable (for e.g. the short blue cables being sold on ebay/ali 50% of those don't work at all, and the other 50% work if there's no lot of interference around them) ... see if you have usb cable you got with some MFP printer, those are usually great ... also, check, doublecheck and tripple check power to the rpi and remove that 5Vusb tape you added
I have started to get the same problem the last few weeks 
Octoprint on my Pi 3B + have been working well on my Ender 3, but suddenly it has started to get "communication error" mid print.. and about 50% fail rate is starting to become a problem 
Any suggestions is welcommed to say it mildly hehe
Start by posting octoprint.log and a serial.log or the contents of the Terminal tab showing the problem. It's impossible to diagnose the reason for timeout issues without seeing the communication with the printer.
I am having the same issue. My tevo tornado has been printing fine but the last couple days everytime i connect thru octoprint, it will start heating and the my breaker will trip. But if i preheat it through the printers screen with the preset values, it heats up normally. It will also give me the same communication errors and will not work. I have reflashed octoprint and my tevo tornado firmware several times and cannot get it to work normally.
octoprint (1).log (82.5 KB)
It looks like your firmware took a nap and stopped responding so OctoPrint gave up. Per the log, the firmware suggests that it can do autoreporting of temperature but I see no indication of temps coming back from it; it died before that got initiated, I'd guess.
When I print through SD it now works fine and has with octoprint, but now out of nowhere it quits. Could it be my board? I have the MKS Gen L V1.0. it has gone through alot of power shortages due to the breaker tripping, could it have friend something important with communicating through the USB serial in the process? I have a new board coming in and will give that a try to see if anything changes. It also stays connected to octoprint and will even do movements and send the print, but after a minute it disconnects.
I'm pretty sure that foosel asked for the serial.log. You'd want to turn that feature on in Settings, run your printer until it misbehaves and then to upload that here.