Hi Sean, Two statements made me feel it's the timing. With the 3rd it was even more evident. The old machine: "Apart from the usual idiosyncrasies associated with Microchip products it serves me well even if it is a bit slow compiling." The new machine: "Earlier this year I bought a used Thinkpad laptop running Windows 8 (32 bit) and decided to use that as my lab machine since it was newer and faster and took up less desk space. So I installed MPl8.92, shifted the ICD2 and set about programming. Unfortunately programming under the debugger fails with the ICD0083 message." How he got it working on the new machine: "But today my son, visiting for Christmas, installed something called Virtual Box which allow me to run XP in a window on the laptop And to my amazement I can use MPL8.92 successfully in this scenario." This is what I understand: #1. The old machine was slow and the I/O on the cable was okay. #2. The faster userspace I/O on the newer system, caused a higher data rate on the cable, which directly affected crosstalk. This broke communication. #3. Now, the faster machine has a virtual machine, which slows down all I/O= .. App->VM->OS->USB->serial in comparison to App->OS->USB->serial (The additional introduction of the VM makes things working for him: all hi= s I/O is now delayed. Indirectly, it implies the same issue that the edges ar= e too fast for his cable. He needs to slow down the edges. :-) R-C filter to damp it ? :-) Does that work ? points to FEXT, I must say) In my situation, I had an even more funnier situation. The machine was the same, but if i used a newer cable it would work for a few days. That cable would behave exactly the same as the old one. Cable had no issues. Eventually, I figured out that humidity and physical handling the cable a few times had some effect to the cheap chinese cable. Likely the cable behaved like a Transmission Line (?) with an increasing capacitance over time due to a myriad factors. Userspace drivers are okay if done correctly. But when userspace drivers are available, it gives the user a chance to make clumsy stuff. But whereas an in kernel driver, if you do that, everything blows apart. So, the user i= s forced to write good applications in case of a kernelspace driver. The downside is that a kernelspace driver is more difficult to handle in comparison. This is the prime reason why the Linux kernel drags people to go with kernelspace drivers instead of userspace drivers. Cheers, Manu On Mon, Jan 1, 2018 at 10:16 PM, Sean Breheny wrote: > Hi Manu, > > I never heard the term NEXT/FEXT before and when I Google it, it seems to > be talking about physical crosstalk. What does that have to do with the > timing issues you mention? > > Just trying to understand! Thanks. > > Sean > > > On Mon, Jan 1, 2018 at 10:26 AM, Manu Abraham > wrote: > >> >> https://msdn.microsoft.com/en-us/library/windows/hardware/ >> ff540207(v=3Dvs.85).aspx >> >> WinUSB is a User Mode Driver framework, Kernelspace drivers comply more = to >> timing restrictions etc etc.. So, the userspace timing dictates your bus >> timing. >> This is dictates your Near END/ Far END (NEXT/FEXT) crosstalk. IIRC >> correctly, >> I've gone through this specific problem. Olin Lathrop has had a >> suggestion for this >> issue on this ML, a long time back. This did fix the issue for me. >> > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .