USB comms

[EFIRick]

Coming from a MS background I have had some miserable experiences with noise interfering with USB.

I have had to minimize USB cabling and use RS232 to eliminate lockups and other nasty's.

I cant even use a USB mouse, must use bluetooth.

Is this an Asus Eee PC 900 issue? Or will I see similar issues with the FreeEMS?

[Fred]

FreeEMS has a much higher data rate than MS products which use inefficient polling instead of back-to-back streaming. What this means is that it'll tax your communications and laptop CPU a bit more than M$ would. An ancient EEE 900 isn't particularly fast, however I used my 10" EEEs for a LOT of FreeEMS work and they were fine with Debian on them. I've also successfully used a crappy Celeron laptop for logging/tuning duties.

I've had USB issues from time to time, usually with noisy setups. Other vehicles have been utterly reliable and consistent. Jaguar has fully isolated comms, so in theory you'll have no ground loop issues with it. In practice, the USB cabling itself is susceptible to noise and can cause device dropouts/swaps etc.

For me, at least, most of the time it's fine. Others may comment with better/different/worse experiences, and I hope they do.

Fred.

[EFIRick]

Thanks Fred, yes ground looping was one issue when I had a laptop with a bad battery and tried to power from vehicle.

How do I determine USB cable shielding quality? Braided, or spun? (spun is more flexible).

I have had so much trouble with USB I have 6 or 8 different adapters that I juggle until one works.

The big clue here may be that a corded USB mouse will cause problems, Im thinking an new tuning computer may be in my near future.

Is USB 3.0 going to be more friendly?

98% of my MS problems have been due to USB issues, beside the lame self immolating installs (not mine)

[EFIRick]

"FreeEMS has a much higher data rate than MS products which use inefficient polling instead of back-to-back streaming.
What this means is that it'll tax your communications and laptop CPU a bit more than M$ would."

I wouldn't expect USB comms to pull down performance much

"An ancient EEE 900 isn't particularly fast, however I used my 10" EEEs for a LOT of FreeEMS work and they were fine with Debian on them."

Mine has been rock solid barring the USB issues. XP runs very well after increasing the SSD size and speed.

"I've also successfully used a crappy Celeron laptop for logging/tuning duties."

I'm looking at a quad core Intel Asus, but the 15" screen inside a car seems sort of clumsy (but then maybe I can see it without reading glasses!) :^)
Most of the smaller offerings seem to be tablets, I don't think EFI tuning is processor, memory, or video intensive.
Battery life and hardening (interference rejection) wifi and built in Bluetooth are very desirable.
I'd like to keep the screen size down to 12" for ease of handling in tight quarters.
Any suggestions?

[EFIRick]

Noise hardening (interference rejection) is not a feature listed in any PC reviews.

I'm not sure a "ToughBook" is still made or better shielded, besides economic considerations and sucky batteries.

Will USB 3.0 have better noise rejection? Will it retain that rejection when a 2.0 device is connected?

Or was the USB on the EeePC 900 so ancient or cheap it is more susceptible?

I'm asking so many questions because I don't want to spend the price of a full FreeEMS on a computer that crashes the same as this EeePC.

I am certain that USB noise is the issue as a Msoft corded mouse plugged in will tilt XP and some adapters will cause TunerStudio to loose it's mind on some installs. While there are no issues seen on a test bench with even the worst adapters.

I'm also curious what devices in the car are causing the interference. Can a stereo radiate enough noise to screw with a PC? My last patient was loaded with audio gear and was the worst noise wise.

I realize this is a reach of sorts from FreeEMS subject matter but if it for some reason is not significantly less susceptible I fully expect to have problems with comms.

[Fred]

Bigger screen size is a plus for tuning as you often want a lot of data AND an input area (eg table(s)) at the same time. Bigger than 15" might get annoying depending on the car and your knee spacing when seated.

The CPU intensiveness comes from poorly written code and/or live data display stuff (gauges, table tracing, etc). Again, depends in the code, some is shit, and this hurts your machine.

I don't think the PC end is the fault, I think the device and/or comms to the device and/or power to the device is what does it. Jaguar has pretty solid filtering on the device, though, and it still has issues, so I guess it's corrupted comms causing a driver error condition and subsequent drop out.

If you do have comms issues, at least you're protected with the protocol that FreeEMS uses. No dodgy shit will happen to your tune as it often did with M$ (excluding tuner bugs...).

I find thicker cables tend to be better. I got two good ones from digikey and amazon that were about 8 USD each and they've both been fine for me.

Fred.

[lumpensack2003]

It's a good hint to check what is done with the USB-shielding on your PCB:
In noisy environments I noticed that it's better not to connect the shield with GND. On my own PCBs I keep the USB shield isolated from GND and only connected to case or other connectors shields.
Just experiment - doesn't cost a penny and could make a difference ...

Second weak point is VUSB, that is in some cases extremely noisy. If it is used (bus-powered device or only bus-powered transceiver), good filtering is mandatory. In different appnotes of the FTDI232 a ferrite bead in the VUSB line is recommended - though often dropped or replaced by a simple resistor because somtimes hard to obtain. I tried a Pi-filter and solid capacitive decoupling and got a nice, clean supplyvoltage.

GJ

[tmbryhn]

Cool thread!

Thought I could chime in after some testing of my own setup.
Made my own USB/BT expansion board for my own ECU design. Dealing with RS232 adapters sucks living in 2016...
Been testing this setup on multiple vehicles now, both with expensive shielded cables (without ferrite beads though), and non-shielded cables straight from eBay/China.
Have had no issues in normal operation at all with neither of them.
I did manage to torture the thing to the point of comms loss on the test bench, physically wrapping the USB cable around the GSXR pencil coils while reving at high RPMs using an RPM stim, lol.

What I can say for certain is that resistor plugs are considered, at least for my part, as mandatory in a car running EFi and especially with USB comms because of the way lower thresholds when distinguishing between hi/low levels between the datalines compared to RS232.
One would believe USB to be almost infinitely robust because it uses a common mode signal, but it's not that way in the real world unfortunately.

The attached picture is of the rev.B, while the schematic is for the rev.C after I implemented some additional filtering on the power and datalines running from the PC. The rev.B have proven to be stable, but i felt that rev.C was of better worst case design practice

The Pic10F200 is just a USB watchdog monitoring the RX pin transmitting data from the ECU MCU. It will reset the FTDI chipset after eventual comms loss, thus enabling the USB link to get re-established without the need for disconnecting/connecting the USB cable. It has only proven useful when torturing in the test bench

The Bluetooth link will also work with the USB cable connected, and no hardware input is needed to switch between cable and wireless comms.

Ahh, and yes, it's Tuner Studio and not my own firmware... Fred, you know my shit...

[Fred]

Great post, thanks for your input!

The Pic10F200 is just a USB watchdog monitoring the RX pin transmitting data from the ECU MCU. It will reset the FTDI chipset after eventual comms loss, thus enabling the USB link to get re-established without the need for disconnecting/connecting the USB cable. It has only proven useful when torturing in the test bench :lol2:

Nice idea! Would you say it was or wasn't worth it to add this behaviour? I've had some dicey USB issues myself with good cables and the right plugs :-)

[tmbryhn]

Thanks, Fred

I'd say it's a cool feature that distinguishes this particular product from others in a way that it has been given a bit more finesse. But like I mentioned, the control loop has not as of yet been triggered and made a reset in normal operation during mapping/loging along the road.