Com port device not replying

[Andy]

Hi,

I have received a new USB to Serial device.

I'm concerned that It's not working correctly, can someone check me out / advise please....

1. It's on COM3, speed, stopbits etc are all correct.
2. In the Commread example program, I can send 4 bytes of data, but received in zero bytes.
3. It works for my ELM327 interface which does send back 4 bytes.
4. In a terminal program with the ELM, the TX and RX light flash.
5. In the same terminal program, with the new interface only the TX light flashes.

Is this interface working / what does anyone think or suggest?

Thanks,
Andy.

[Andy]

Found the answer,

It seems the device has to be connected at both ends, like a loopback.

Now I can receive data from it.

Andy.

[Andy]

I found something on the manufactures site that say this:

"shoud be made aware the FTxxx is a USB device and not a "normal" RS232 device as seen on a PC.
The device operates on a packet basis as opposed to a byte basis".

So to send commands to this chip do I need
Start of header character - data/command - End of header character?

The commread example sends and reads bytes of data, so is this statement telling me that
although I can open the port It's no good for this chip?

Currently, using the commread example, what ever command I send out is simply sent back during
the read section.

E.g. Sent - Hello
      Reply- Hello

They have two sets of drivers, a virtual com driver (which is what I am using) and their own
Win32 API driver, with their own functions written into their dll file.

If I have to use their own dll functions, would anyone be willing to "modify" them so I can use them in IWB please??

Help please!!

Andy.

[Egil]

I found something on the manufactures site that say this:

"shoud be made aware the FTxxx is a USB device and not a "normal" RS232 device as seen on a PC.
The device operates on a packet basis as opposed to a byte basis".

Most such devices operate on a packet basis. And usually you do not receive any understandable response unless a valid command code is part of the packet. If the manufacturer allow third party software, they usually are able to supply a detailed description of the control packet system ( e.g. the communications protocol).

So to send commands to this chip do I need
Start of header character - data/command - End of header character?

This varies from system to system, but  should be stated in above mentioned protocol description.

The commread example sends and reads bytes of data, so is this statement telling me that
although I can open the port It's no good for this chip?

If that example is provided by the device manufacturer, it should be a valid example on how to use their system(s).
If you mean the IWB commread example, this is just a general example showing how to address a comport, whether real or "virtual" (= using a USB - RS232 converting device).

That the device only echoes whatever you send (if this is really echoed by the device and not just unintenionally printed by your terminal program), only indicates that the connection between your computer and the device is working.

They have two sets of drivers, a virtual com driver (which is what I am using) and their own
Win32 API driver, with their own functions written into their dll file.

Personally I would prefer to use the virtual com driver, as long as the control command system is the same for  both ways.
Converting header files for such DLLs can often be difficult. So if you have a detailed description of the command system, it should be simpler and more reliable to use the virtual com driver.
But always check that you are using the latest update of the driver.


My comments may sound very general, and they are. But to attempt making more detailed comments, I would need a copy the manufacturers communications protocol description.
Such descriptions usually comes with the devices, but can also be sent on demand from the device manufacturer. They use to be very serviceminded.


Good Luck!

Egil

[Egil]

Andy,

I have possibly misunderstood your post. If this is the case, my reply above is just nonsense. I assumed your new device was a replacement for the ELM327 car sensor interface.

But if your new "device" is just to replace a RS-232 serial communications cable, whether a USB/RS-232 converter or not, this should be completely transparent to the users.
So if you are using the latest driver, and still get no response from the ELM327, there is something seriously wrong with the new device.


Egil

Edit: Had written RA-232 instead of RS-232.... sorry

[Andy]

After using several terminal programs including Egil's WTerm I have found this:

1. My ELM327 responds as expected.
2. The new KKL unit is faulty - just bad luck I guess.

I have tried every setting possible, compared the results with the good working ELM and can only conclude point 2, the new device is faulty.

Pitty, as I waited 3 weeks for the device to arrive.

I must now source a new one.

Thanks,
Andy.

[Egil]

Andy,

If there is a new cable involved with you new device, remember to check it before discarding the device. I have all too often experienced that plugs where the pin connections are not soldered, by pressed onto the leads in a machine, have had bad connections.


Egil