I would like to see an app that got even close to 480 Mbits on USB.  I did a few USB projects and speeds could never get very high with USB.  To much Winblows code in the way.  USB 3.0 doesn't help.  The video driver may be different but the other drivers stink on throughput. If I put 2 USB cameras on the same USB root hub on my 3D printer for pick and place it crashes the computer.  Most laptops only have one root hub for users.  Not even close to 480Mbits and the PC can't handle it.   More important it picks up noise and ground loops from the computer which is huge.  Makes analyzing low level signals impossible.  Continuous traffic trashes USB in my experience.  Not going there again. However I have TCP connections doing plenty of traffic with no problems. For POE I use a POE adapter which is a wall wart so the high end router is not needed.  The adapters are cheap now. The problem with high speed printing is generating enough hot plastic so it can move quickly and then a low speed mode for slowing it down.  No mechanism to handle the difference.  I am trying a 3 headed design (diamond) http://reprap.org/wiki/Diamond_Hotend  now.  The top of the printer is off now while I add 2 more extruders.  That has potential to solve the problem.  Smaller heat chambers but 3 of them for speed when needed.  I would post a video of the 3D printer but here it is out of context.  This thread is for Neal. Nice Drone!  Mine has only been 10 inches or so.  No manly ones like yours and your copter.

btw... thanks for the package... .zip! it's great

this low cost grid tie is a single stage inverter with unfold bridge. Input capacitor is crucial!

USB is not that slow. With a FTDI chip for USB 2.0 you can reach up to 480MBits/s.  POE would is something most people do not have at home. Most routers/switches do not have POE capability. Only the more expensive ones have it. But I guess you will make it in such a way that it will be possible to power it with a dc adapter as well. The problem Neal encountered has not been solved as far as I know. I think he got stumped and gave up. I cannot blame him, I would be very frustrated as well. He spend a lot of time on it. He encountered too many tcp resends. We were sampling at 504201 Hz and sending blocks of 1024 samples. Unfortunatly the dspic could barely keep up the data rate. We reached about the maximum SPI rate of 15MHz (tcp has a lot of overhead). When one DMA block was filled with samples the other was send to the PC. But sending through the w5500 is a blocking operation. And if there are one or more resends the sending takes longer. Too long actually. Sending could not keep up the the sampling and glitches occured. Sometimes the dsPic or w5500 stalled completely. Neal got tcp resends very often even with only his pc, analyser and a switch as a separate network. He also tried other pc's and network equipment, with the same result. I was not able to reproduce that problem though. It all worked fine here. But if one of us has trouble then chances are that someone else can will have the same problems. The solution should work for everyone. We also tried UDP, but that did not work out as well. We also cannot affort to loose any data or receive it in the wrong order. So we had to stick with tcp. I think using USB will not have this problem because there is less change of congestion. Its just the analyser and the pc. The current application is written in C# (.NET framework) because that's wat I use as a professional software developer every day. I never used QT, but it looks great. It would be great if the client application would be able to run on other devices like tablets as well. I think QT is free to use when used with a certain open source license model. I like the idea of the brushless motors. I use them with my drones (8 motors, 1m diameter) and model helicopters (1.2m rotor diameter). There is an article about using dc motors with a closed loop pid controller for use in a 3D printer in the last two issues of Circuit cellar. I also have retraction problems like you have. I do not think you can solve that easily. The problem is that retracting the fillament does not create a vaccuum inside the nozzle. Air can get inside easily. So it does not suck the filament back into the nozzle as you would expect. Retracting only reduces the oozing because there is less pressure of the fillament. Therefore there is no use in having more than 2 - 4mm retraction. Don't you have problem with printing layers too fast on top of each other? I never print faster than 60mm/s because if a layer is printed on top of one which has not been able to cool down yet it will become a mess. Even with a fan. I like to see your printer in action. Do you maybe have a movie you can show?

I have not found the article published in English, but you can find BOB-SCAP in german here: https://www.elektormagazine.de/magazine/elektor-201507/27880, and in Dutch there: https://www.elektormagazine.nl/magazine/elektor-201603/28865. Good reading.