[Seek]

I seem to be having an issue that isn't consistent. I can plug the QuarterHorse into the system and it will work and I can start datalogging. Randomly, BE will stop datalogging and I cannot get it to connect back up to the QH. The hardware still appears in the Device Manager but BE cannot connect again. I unplug the usb cord and plug it back in - Windows makes its sound of new hardware and it shows up but BE then starts throwing errors every time I try to datalog about requiring a Moates chip. After unplugging it and plugging it back in a few times, I finally get the "QuarterHorse 1.2" popup somewhere randomly onscreen in BE and I can datalog again...until it randomly fails once again. This random connection failure can be anywhere from a minute, or up to 30+ minutes. I have it attached without the usb extension so I know it isn't cable length and I've tried different usb ports that are separate from one another (not the ports next to one another).

Without another application to test, it is hard to know if it's the QH or BE that's losing its connection but since it still appears and removes/installs the device every time I mess with the usb cord, I have to believe that BE is the one losing the connection. Any ideas?

[cgrey8]

I've been having that same exact problem, but blaming it on my USB Hub. I'll go back to using the DataQ and QH without the hub and see if I still get this. The sad part is I don't think this is BE's fault. I suspect this is probably a Windows or an FTDI driver issue screwing up the way the device appears to BE. Thus BE is requesting info on what it identifies as COM devices on ports it expects devices to be on, but the responses from those devices is not lucid or no response at all, yet Windows allows BE to open the COM port and thus leads BE to believe it is "connected" to the device.

Regardless of where the problem is, it's frustrating. I'm sure it's more frustrating to Clint since I honestly don't think this is a problem he has direct control over. Short of finding a .NET way to work around the problem or to possibly "reset" a USB connection at will to reinitialize the drivers like you are doing when you unplug the device and reconnect it, I'm not sure what he'll be able to do about it other than work with FTDI on the issue.

But one thing that might help is for BE to keep detailed error logs. Instead of requiring the user activate a log to test when things go bad, have BE save off pertinent info all the time, but only save it to the HD when something unexpected happens so the details of the problem are saved from when it happened. Unfortunately, this has been my typical experience with USB devices. I thoroughly hate USB and wish we could have a device with a better interface other than USB. Firewire is just too expensive to implement. And Ethernet too complicated. So USB is what we got.

[86GT]

I can trie to set some of the parameters up in the USB driver. Maybe the defaults are not good. I will try and set the timeouts to a full second to see if that helps. Yes I can also rest the device but I need to know when and so on.

Let me dig a little more.

[cgrey8]

The time to try resetting the USB is when BE can see that Windows has a COM port names "Moates" and a device called "Quarterhorse" in the list. If these exist, yet BE is not able to communicate to it, it's time for a USB reset.

[SigEpBlue]

Just to throw my hat in the ring, I'm having the same issue. I got logging to work (I think...) for a second or two, but it kicks out just as the OP described.

No worries; I'm having a great time writing research papers over spring break right now anyway.

[86GT]

I am currently looking into this.

[Dale McPeters]

Clint,

I am having the same problem ........

[86GT]

It appears that two people have solved this if they use a cable with a ferrite on it. Craig mentioned to me that he will be sending out new USB cables to all of those that have purchased a QH. This maybe why i never saw the issue, mine has a ferrite on it already.

If you have a digital camera or cell phone cable that has the ferrite on it, try it and let us know.

[cgrey8]

Unfortunately most cables with ferrite beads on them are molded to the cable so you can't easily disassemble the bead pack and install it onto another wire.

Also note, my QH setup does have the ferrite bead pack on the QH end of the wire. However the ferrite bead pack is INSIDE the EEC, not external. So if there is electrical noise being generated inside the EEC, part of the wire AFTER the ferrite bead pack is exposed to it. Tomorrow, I'll try relocating the bead pack outside the EEC and see if that works any better.

[Craig Moates]

No worries on this, I'm with you guys. We'll get it taken care of. Thank you for your patience in these early days.

[BobCat]

I've tuned 4 vehicles with the QH so far and only had the disconnect issue on one of them. It seems as though after I followed these instructions and making sure I write the first tune to the device BEFORE it is installed remedied my problems.

"The new BE requires you to have the latest FTDI drivers. If you get errors while running BE with the TwEECer and or Moates hardware then you need to update the drivers. To update the drivers do the following after BE is installed.

Take the drivers in the following:
C:\Program Files\Binary Editor\Drivers\i386\

and copy to :
C:\Windows\System32\"

FYI Today I nailed down a 360ci 2.2KB 60lb inj SCT MAF car in about an hr with the customer driving.....it would have taken 3-4 hours with a TwEECer.

Also I logged a GUFB and a GUF1 for over an hour today while tuning and it never disconnected.
Many thanks to Craig and Clint

[86GT]

Cool I am glad that it is working on some. It is jusst frustrating to track down a moving target.

[Dale McPeters]

Clint,

Well the latest download did not help...Still having issues..

I will try a usb cable with the ferrite bead that is able to be installed in the eec.....the one I told you I would try last night had the bead close to the large side conection. Also it did not work even with the latest download....

Will drop you an email later..

Also remember that this is a V1.3 board with V1.2 QH firmware.

[86GT]

ok that board and frimware are identical to what i have.

[Craig Moates]

The 1.3 board and 1.2 FW are the latest in the field. There will be another update, 1.3 FW, but it will not have any effect on what's going on here. That should be available by the beginning of the week, but there is no discernable difference from the users' standpoint.

[BobCat]

FWIW on the one occasion that I was having problems I was using the USB extension cable, I have not used it since so I cannot attest to whether or not it had anything to do with the communication error.

[Dale McPeters]

no extension cable......

By the way my Ostrich 2.0 and J3 burner seem to be working fine.......so I do not think it is my usb cable....

By the way this is with Clint's new software and Paul's old software on the above...

[86GT]

So pauls software is giving the same results with QH?

[Dale McPeters]

So pauls software is giving the same results with QH?

He has not released any software for the QH yet......I am still waiting...
I have been using the last version that he released just to make sure that the Ostrich 2.0 and
J3 burner were still working.

By the way I am going to try something different in a little bit....

Just got back from taking my wife out to eat for our anniversary.....

[86GT]

Happy anniversary by the way

I was not sure if Paul had is out yet. I was looking at the cables today and read that all USB 2 cables had to be stamped as such. Not sure how true this is but I thought that I would throw that out there.

I will have anothere build in a few minutes. It fixes a small bug when having both the QH and DataQ connected at the same time.

[Dale McPeters]

Thanks...

Drop me a line and I will download it and try it out....

[86GT]

Thanks...

Drop me a line and I will download it and try it out....

Done 2009 Build 9 is up

Were you trying it with the DataQ too or just QH by itself? Just for testing make sure the QH is the only thing selected on the hardware tab and the goto the config on the QH and set the AutoStop to say 60 and try that.

[Dale McPeters]

Yes with the dataq.....but I just got through disconnecting it for this test. I have already set the QH Auto stop to 60 as we discussed last night.

I will download the latest and give it a try and if it works I will hook the dataq back up
and see what happens.

By the way just an FYI all the cables that I have tried have been usb 2.0.
One with ferrite and two without....

[Dale McPeters]

well the latest build did not help.....

It still keeps telling me that the QH failed to set the tune selection.....

If I am the only one that is having the problem of polling/data logging the QH maybe it is a QH
hardware problem? Maybe a bad board?

My J3 and Ostrich seemed to still be working fine today...

I will try another trick tomorrow and see what happens and if that does not work will see if Craig
can send me another board to test with.....

[Dale McPeters]

By the way when I do this testing I burn the tunes on the bench and everything works fine...

Then I put it in the car, that is when the problems begin. It acts to me like the QH is not taking full control of the calibration console with this board?

But like I stated before my Ostrich 2.0 and J3 Burn items seemed to be still working fine this morning.
I will try them with this latest build tomorrow and see what happens.......

[86GT]

It was reported to me today that after downloading the QH does not repsond until the tune selection is changed and the reverted back. I have not tested this myself.

[Dale McPeters]

It was reported to me today that after downloading the QH does not repsond until the tune selection is changed and the reverted back. I have not tested this myself.

Already tried that.....

Check your email.

[BobCat]

Try this...
Write the tune to the QH with the board removed
Install the QH and write once again with the key off
Key on and try datalogging

This method has seemed to work everytime now for me.

[Dale McPeters]

Try this...
Write the tune to the QH with the board removed
Install the QH and write once again with the key off
Key on and try datalogging

This method has seemed to work everytime now for me.

I have already done that numerous times but will try it again after while..

Right now I am testing another eec just to see what happens...

[Dale McPeters]

No luck with two different eec's........

The BE/QH still will still not datalog/poll.....

It will datalog about 45 sec. by burning the tune on the bench, install QH in car, turn key to on position, hit start button in BE.
Logging starts at this point and about 10-15 sec. after starting the car it looses connection and car goes nuts.....then can not re-connect at all until I shut down BE and restart and update the tune in the QH....