Bluetooth serial connection vs. USB serial connection

[ruutboy]

Hi guys,

I have a Bluetooth connected HART modem (don't worry too much about the HART aspect, and it's modem-ish), which with complient software (i.e. PACTWare) works fine.

Unfortunately, one of the devices that I have to connect to uses their own software and it refuses to talk to the Bluetooth modem.

Ok, fine. So I wrote a serial port redirector with the thinking that I would use two USB to RS232 adapters and a null modem cable and have the software go out one of the USB ports, into another (which was the incoming port for my program), and then out the Bluetooth port (which is the outgoing port in my program) to the device, and then back again.

Yeah, my head hurts too.

I've glossed over the details to try to keep this message short, but the gist of all of this is that I am replacing the Bluetooth modem (from the vendor's perspective) with a USB one.

My program doesn't quite get to 100% of the parameters loaded in (best so far is 92%), but unlike the connection directly through the Bluetooth port it does connect, and download much of the data.


So my question is what's different between a Bluetooth serial connection and a USB serial connection? And where would I start in figuring out these differences? (I've tried a serial port sniffer with the result in finding out that if the Bluetooth modem was connected directly to the vendor's program, the vendor's program would never even try to send data out the serial port. But if I do it through my convoluted little program, it not only connects, but it gets most of the way there.


Thanks!

[Jan Axelson]

To see if I understand correctly:

You have a device and a Bluetooth modem that each connect to the same PC?

And you want to receive data from the device and send the data to the modem?

And you want to use software from the device's vendor to do so?

Some things I would check:

Can the vendor program find the Bluetooth modem's COM port?

Are the parameters correct - flow control, data bits, etc.?

[ruutboy]

To see if I understand correctly:

You have a device and a Bluetooth modem that each connect to the same PC?

The Bluetooth modem connects to an industrial device, which is HART programmable. The reason why I chose to use Bluetooth is because in one area of our plant we dip the car bodies in electroplating "goo". Really, really, sticky stuff, and this allows me to put the modem in a baggies to prevent it (and the laptop, which is several feet away) from getting sticky.

And you want to receive data from the device and send the data to the modem?

I already do for every HART programmable device except the one for the DrexelBrook level transmitter. The industry standard is to create your own DTM (a fancy driver created by the manufacturer of the device that gets called from PACTWare) and integrate it into PACTWare.

And you want to use software from the device's vendor to do so?

I pretty much have to. They naturally control the format of the data going to and fro from their device, and short of reversing it, I have to use their software.

Some things I would check:

Can the vendor program find the Bluetooth modem's COM port?

Nope. But they aren't looking for them either. Their program strictly accesses a COM port. What you have connected to it is your concern.

And this is the crux of the matter, all they ask for is a COM port. Baud rate, parity, data bits, and stop bits are all predefined in the HART protocol spec (1200 baud, 8 data bits, odd parity, and one stop bit). Any changes to these parameters in Windows Device Manager will be ignored. You can set them up in any way that you like. Parameters changed outside of this group (i.e. Handshaking) will have an effect (for example, setting handshaking to "Hardware" will always make the connection fail)

But somehow the software knows that this isn't quite a normal COM port. Using a serial port monitor, I can see that it doesn't even try to send anything out the COM port if COM port selected is the one that the Bluetooth is connected to. Using my "loopback" setup and connecting the software to a normal port, and then using my program to do the talking to the Bluetooth modem will get me most of the parameters. So there is something at some level that is different on the modem than there is on a standard COM port. Weird...

And I keep referring to the Bluetooth modem as a modem because it uses the DCD (or CD, Carrier Detect) line the way that a modem would (but doesn't use the AT command set). CD is brought high when the Bluetooth modem is turned on. And I believe that this is the proper behavior. One of the tests that I would like to make is to see if the CD line is dropped or its operation is somewhat modified due to the additional RS232 devices in the link.

Are the parameters correct - flow control, data bits, etc.?

Yup. The end user doesn't have much say in the matter either. The modifiable parameter is flow control, and it must be set to "None"


Thanks Jan for looking into this!

John

[Jan Axelson]

The Bluetooth connection is between a Bluetooth port/adapter on the PC and the modem?

And the modem is hard-wired to the HART device?

Maybe this has something to do with it the Bluetooth SPP says:

it is optional to use all RS232 control signals except flow control (the RTR signal in TS 07.10 [5]). This signal can be mapped on RTS/CTS or XON/XOFF or other API mechanisms, which is an implementation issue.

Informative note: To provide interoperability between devices actually using all RS232 control signals, and devices not using them, the former type of implementation must set the states of the appropriate signals in APIs/connectors to suitable default values depending on RFCOMM DLC state. The implementation must not rely on receiving any RS232 control information from peer devices. The dependency on RFCOMM DLC state may mean that DSR/DTR, as well as DCD, is set to high level when an RFCOMM DLC has been established, and that the same signals are set to low level if the corresponding DLC is closed for any reason.

https://developer.bluetooth.org/TechnologyOverview/Pages/SPP.aspx