[garyhgaryh]

Originally Posted by HighVoltage

I would just get a hold of a couple db9 ends in the right gender(s) and put one together. Be sure to address both the CTS/RTS and the DTR,DSR and DCD. I didnt see you mention DTR, DSR and DCD. You may need to tie these together as well. Also, although unlikely it may be looking for the RI as well. In that case you may have to tie that to the DTR/DSR/DCD.

I'm going to my workshop right now. I have a bunch of these db9 connectors. I don't know where my soldering iron is...

I did mention DTR,DSR, and DCD, but not explicitly... see msg #23 where I mentioned pins 1, 4, and 6.
CTS/RTS pins 7 and 8 (msg #18).
Gary

[HighVoltage]

Originally Posted by garyhgaryh

I'm going to my workshop right now. I have a bunch of these db9 connectors. I don't know where my soldering iron is...

I did mention DTR,DSR, and DCD, but not explicitly... see msg #23 where I mentioned pins 1, 4, and 6.
CTS/RTS pins 7 and 8.
Gary

Ah, ok. That should cover it then...

[HighVoltage]

Originally Posted by scalbert

I beleive the IOGear unit is 9 VDC, but will need to check.

The dropping of connection during and upload is a concern which I suspect we will need to test or consult with Vishnu about.

Ya especially considering the Bluetooth operating freq is in the same range as some cordless phones (2.4ghz) and 802.11b.

802.11a would help eliminate some of these concerns...

[garyhgaryh]

well, i just verified the serial port on the procede is a 3 wire rs232 interface. We're getting close!!


re-edit: ok, munter mentioned it is 3 wire! Had to verify it myself. Pins 2, 3, and 5 are used on the procede.

[NM_BMW]

Originally Posted by garyhgaryh

well, i just verified the serial port on the procede is a 3 wire rs232 interface. We're getting close!!


re-edit: ok, munter mentioned it is 3 wire! Had to verify it myself. Pins 2, 3, and 5 are used on the procede.

I guess if you couldn't find an adapter that wasn't molded you could make your own 9pin cable with 7and 8 crossed. Though it would look weird on your laptop going from usb/serial > home made db9 cable > bluetooth.

[garyhgaryh]

I can't get it to work for some reason.
I tied pin 7 and 8 (rts/cts) - same result (doesn't work).
I then tied pin 1,4, and 6 - same results.
I'm tying the pins on the iogear side and break the connection going to the procede's db9 (it's not connected on the procede side so it doesn't matter anyways).

Now I wonder if I have other issues - I'm sure my GF thinks that.

I spent as much for adapters and the breakout box as I did for the iogear serial bluetooth adapter!

[munters]

Originally Posted by e.n335

Great solution, munters

As you know, it was your solution at your Procede Times. I'm still happy with it

[zenmaster]

I've got the GBS301 also - will help test. I started this project over a year ago, but it got stalled.

An inverter doesn't make much sense. The simple regulator circuit used in a variety of cigarette power adapters should work as a power converter. Just pick up one for a device that provides the correct voltage (5v) and at least the current rating (300ma) or use any USB cigarrette 12VDC-5VDC car adapter (should be around $10), or just buy something like this. The DC power plug to use is a 2.35/0.7mm with positive tip (can rip it from the AC adapter).

It is entirely possible that some communication problems can be due to the PC's bluetooth-stack software, rather than with flow control. Be aware that not all bluetooth stacks implement the serial-port (SPP) virtualization in a manner that is compatible with all software that uses PC COM ports (e.g. Procede Reader). However, information from similar projects suggests that one of the best stacks for this purpose is Broadcom's, which is used by AnyCOM's Bluetooth USB adapter.

The Procede's serial-port wiring diagram is here. It's just RX, TX and ground.

I did verify that the PROcede software can successfully open the COM4 port using the Broadcom stack. But that's it, I have yet to try it on the car.

BTW, the GBS301 uses the earlier version of bluetooth. It doesn't support frequency hopping, which provides a much more robust link in the presence of radio interference. That said, it's only going a few feet so may not be a big deal.

[zenmaster]

Originally Posted by HighVoltage

If you are really ambitious (+ more $) you might want to consider a wifi-RS232. Shouldnt be any issues with data logging and an industrial version should have a wide input range for the source voltage.

Procede provides real-time data logging. Usable real-time data logging requires low latency. Bluetooth adds about 10ms. How's the latency using wifi-rs232?

[cn555ic]

Wow this is interesting, but for the record, the USB to glove box saves so much time and money IMHO!

[HighVoltage]

Originally Posted by zenmaster

Procede provides real-time data logging. Usable real-time data logging requires low latency. Bluetooth adds about 10ms. How's the latency using wifi-rs232?

Please clarify "real-time". Does the Procede force feed the data or does the app have to request the data? At what intervals is this occuring? How much data is transferred? How deep is the Procedes buffer?

Wifi isnt all that far removed from any other gateway/bridge. You will typcially configure the device to gather up so many bytes off the serial port before transmitting the data to maximize your bandwidth (i.e throughput). Latency is highly dependent on the platform as well as the physical layer. Having said that, wifi platforms typically have a bit more horsepower to handle the TCP/IP stack and MII interface than compared to bluetooth.

10ms seems like an arbitrary number. Under what conditions was this obtained?

[zenmaster]

Originally Posted by HighVoltage

Please clarify "real-time".

Simply that there is no noticeable delay from measurement to presentation of an actively changing value (RPM, TPS, boost, speed, etc).

Originally Posted by HighVoltage

Does the Procede force feed the data or does the app have to request the data? At what intervals is this occuring? How much data is transferred? How deep is the Procedes buffer?

I haven't measured these, and don't know if it's push or pull. I do know that Eugen found (not surprisingly) the back-to-back Sena solution to be a little too slow for real-time (presumably real-time delay would be doubled).

Lacking a scope or analyzer, something like this tool may help with that.

Originally Posted by HighVoltage

10ms seems like an arbitrary number. Under what conditions was this obtained?

It is arbitrary - taken from some info here here, here, here and could represent best case. No actual measurements have been made yet, so frame size, round-trip delay, etc are unknown.

[garyhgaryh]

Originally Posted by zenmaster

I've got the GBS301 also - will help test. I started this project over a year ago, but it got stalled.

An inverter doesn't make much sense. The simple regulator circuit used in a variety of cigarette power adapters should work as a power converter. Just pick up one for a device that provides the correct voltage (5v) and at least the current rating (300ma) or use any USB cigarrette 12VDC-5VDC car adapter (should be around $10), or just buy something like this. The DC power plug to use is a 2.35/0.7mm with positive tip (can rip it from the AC adapter).

It is entirely possible that some communication problems can be due to the PC's bluetooth-stack software, rather than with flow control. Be aware that not all bluetooth stacks implement the serial-port (SPP) virtualization in a manner that is compatible with all software that uses PC COM ports (e.g. Procede Reader). However, information from similar projects suggests that one of the best stacks for this purpose is Broadcom's, which is used by AnyCOM's Bluetooth USB adapter.

The Procede's serial-port wiring diagram is here. It's just RX, TX and ground.

I did verify that the PROcede software can successfully open the COM4 port using the Broadcom stack. But that's it, I have yet to try it on the car.

BTW, the GBS301 uses the earlier version of bluetooth. It doesn't support frequency hopping, which provides a much more robust link in the presence of radio interference. That said, it's only going a few feet so may not be a big deal.

I went to the sony outlet store in gilroy this past weekend and noticed a 5Volt cigarette lighter adapter. I'm getting one of those and ripping it apart for the 5volt circuit or building one of these:

http://members.tripod.com/RoBoJRR/projects.htm (uses the 7805 in your link)

Go to 7. 9Volt to 5Volt Harness for GBS301 Serial Bluetooth

I'm using the broadcom stack.

Gary

[garyhgaryh]

Originally Posted by zenmaster

Lacking a scope or analyzer, something like this tool may help with that.

Nice tool. I used it to trace what happens when I connect via com1 and com4 (which is the bluetooth comport - btcom).

With BT, I can open com4, but when I connect online, something happens and then the connection to the procede via BT is disconnected.

Right before the disconnect, the following request is issued:

44 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_SET_TIMEOUTS BtPort2 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC: -1172264056


Look at WC which I believe is the WriteTotalTimeoutConstant. It's negative.
On the "good" log with the procede connected directly to com1 via cable, the request is:

44 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:5000


Anyone have any ideas what's going on? I'll include the good and bad log below. Ignore the fact that the "bad" log's init baud rate is 115200 (that was just a test).

Good log: procede connected to com1 (hardwire)
-------------------------------------------------
0 0.00006034 Pde_reader v3_1 IRP_MJ_CREATE Serial0 SUCCESS Options: Open
1 0.00000475 Pde_reader v3_1 IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR BRK ERR
2 0.00000223 Pde_reader v3_1 IOCTL_SERIAL_GET_TIMEOUTS Serial0 SUCCESS
3 0.00000223 Pde_reader v3_1 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:5000
4 0.00000363 Pde_reader v3_1 IOCTL_SERIAL_GET_BAUD_RATE Serial0 SUCCESS
5 0.00000223 Pde_reader v3_1 IOCTL_SERIAL_GET_LINE_CONTROL Serial0 SUCCESS
6 0.00000223 Pde_reader v3_1 IOCTL_SERIAL_GET_CHARS Serial0 SUCCESS
7 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_HANDFLOW Serial0 SUCCESS
8 0.00001062 Pde_reader v3_1 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 9600
9 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_SET_RTS Serial0 INVALID PARAMETER
10 0.00000782 Pde_reader v3_1 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS
11 0.00000419 Pde_reader v3_1 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
12 0.00000223 Pde_reader v3_1 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:0 XOFF:0
13 0.00000754 Pde_reader v3_1 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace:40 XonLimit:0 XoffLimit:0
14 0.00000251 Pde_reader v3_1 IOCTL_SERIAL_GET_BAUD_RATE Serial0 SUCCESS
15 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_LINE_CONTROL Serial0 SUCCESS
16 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_CHARS Serial0 SUCCESS
17 0.10629172 Pde_reader v3_1 IOCTL_SERIAL_WAIT_ON_MASK Serial0 SUCCESS
18 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_HANDFLOW Serial0 SUCCESS
19 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_BAUD_RATE Serial0 SUCCESS
20 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_LINE_CONTROL Serial0 SUCCESS
21 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_CHARS Serial0 SUCCESS
22 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_HANDFLOW Serial0 SUCCESS
23 0.00001034 Pde_reader v3_1 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 57600
24 0.00000559 Pde_reader v3_1 IOCTL_SERIAL_SET_RTS Serial0 SUCCESS
25 0.00000531 Pde_reader v3_1 IOCTL_SERIAL_SET_DTR Serial0 SUCCESS
26 0.00000391 Pde_reader v3_1 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
27 0.00000223 Pde_reader v3_1 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:0 XOFF:0
28 0.00000419 Pde_reader v3_1 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace:40 XonLimit:0 XoffLimit:0
29 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_BAUD_RATE Serial0 SUCCESS
30 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_LINE_CONTROL Serial0 SUCCESS
31 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_CHARS Serial0 SUCCESS
32 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_HANDFLOW Serial0 SUCCESS
33 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_BAUD_RATE Serial0 SUCCESS
34 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_LINE_CONTROL Serial0 SUCCESS
35 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_CHARS Serial0 SUCCESS
36 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_HANDFLOW Serial0 SUCCESS
37 0.00001006 Pde_reader v3_1 IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 57600
38 0.00000531 Pde_reader v3_1 IOCTL_SERIAL_CLR_RTS Serial0 SUCCESS
39 0.00000531 Pde_reader v3_1 IOCTL_SERIAL_CLR_DTR Serial0 SUCCESS
40 0.00000363 Pde_reader v3_1 IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
41 0.00000223 Pde_reader v3_1 IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:0 XOFF:0
42 0.00001062 Pde_reader v3_1 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:0 Replace:80000000 XonLimit:0 XoffLimit:0
43 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_TIMEOUTS Serial0 SUCCESS
44 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_SET_TIMEOUTS Serial0 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:5000

45 0.00002822 Pde_reader v3_1 IRP_MJ_WRITE Serial0 SUCCESS Length 1: .
46 0.00000447 Pde_reader v3_1 IOCTL_SERIAL_GET_COMMSTATUS Serial0 SUCCESS
47 0.00312330 Pde_reader v3_1 IOCTL_SERIAL_WAIT_ON_MASK Serial0 SUCCESS
48 0.00000587 Pde_reader v3_1 IRP_MJ_READ Serial0 SUCCESS Length 1: .
49 0.00002486 Pde_reader v3_1 IRP_MJ_WRITE Serial0 SUCCESS Length 3: ...
50 0.00000503 Pde_reader v3_1 IOCTL_SERIAL_GET_COMMSTATUS Serial0 SUCCESS
51 0.00000587 Pde_reader v3_1 IOCTL_SERIAL_WAIT_ON_MASK Serial0 SUCCESS
52 0.00000251 Pde_reader v3_1 IOCTL_SERIAL_GET_COMMSTATUS Serial0 SUCCESS
53 0.24998065 Pde_reader v3_1 IOCTL_SERIAL_WAIT_ON_MASK Serial0 SUCCESS
54 0.00000670 Pde_reader v3_1 IRP_MJ_READ Serial0 SUCCESS Length 7: ...eg..
55 0.00000615 Pde_reader v3_1 IRP_MJ_READ Serial0 SUCCESS Length 0:
56 0.00003464 Pde_reader v3_1 IRP_MJ_WRITE Serial0 SUCCESS Length 6: ......
57 0.00000447 Pde_reader v3_1 IOCTL_SERIAL_GET_COMMSTATUS Serial0 SUCCESS
58 0.00000587 Pde_reader v3_1 IOCTL_SERIAL_WAIT_ON_MASK Serial0 SUCCESS



bad log: procede connected to com4 (via bluetooth)
-------------------------------------------------
0 0.00028216 Pde_reader v3_1 IRP_MJ_CREATE BtPort2 SUCCESS Options: Open
1 0.00000419 Pde_reader v3_1 IOCTL_SERIAL_SET_WAIT_MASK BtPort2 SUCCESS Mask: RXCHAR BRK ERR
2 0.00000223 Pde_reader v3_1 IOCTL_SERIAL_GET_TIMEOUTS BtPort2 SUCCESS
3 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_SET_TIMEOUTS BtPort2 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:208180216
4 0.00000279 Pde_reader v3_1 IOCTL_SERIAL_GET_BAUD_RATE BtPort2 SUCCESS
5 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_LINE_CONTROL BtPort2 SUCCESS
6 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_GET_CHARS BtPort2 SUCCESS
7 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_HANDFLOW BtPort2 SUCCESS
8 0.00006006 Pde_reader v3_1 IOCTL_SERIAL_SET_BAUD_RATE BtPort2 SUCCESS Rate: 115200
9 0.00000643 Pde_reader v3_1 IOCTL_SERIAL_SET_RTS BtPort2 SUCCESS
10 0.00000531 Pde_reader v3_1 IOCTL_SERIAL_SET_DTR BtPort2 SUCCESS
11 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_SET_LINE_CONTROL BtPort2 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
12 0.00000559 Pde_reader v3_1 IOCTL_SERIAL_SET_CHAR BtPort2 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:0 XOFF:0
13 0.00000503 Pde_reader v3_1 IOCTL_SERIAL_SET_HANDFLOW BtPort2 SUCCESS Shake:1 Replace:40 XonLimit:0 XoffLimit:0
14 0.00000223 Pde_reader v3_1 IOCTL_SERIAL_GET_BAUD_RATE BtPort2 SUCCESS
15 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_LINE_CONTROL BtPort2 SUCCESS
16 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_CHARS BtPort2 SUCCESS
17 1.19142992 Pde_reader v3_1 IOCTL_SERIAL_WAIT_ON_MASK BtPort2 SUCCESS
18 0.00000223 Pde_reader v3_1 IOCTL_SERIAL_GET_HANDFLOW BtPort2 SUCCESS
19 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_GET_BAUD_RATE BtPort2 SUCCESS
20 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_GET_LINE_CONTROL BtPort2 SUCCESS
21 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_GET_CHARS BtPort2 SUCCESS
22 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_HANDFLOW BtPort2 SUCCESS
23 0.00004302 Pde_reader v3_1 IOCTL_SERIAL_SET_BAUD_RATE BtPort2 SUCCESS Rate: 57600
24 0.00000559 Pde_reader v3_1 IOCTL_SERIAL_SET_RTS BtPort2 SUCCESS
25 0.00000531 Pde_reader v3_1 IOCTL_SERIAL_SET_DTR BtPort2 SUCCESS
26 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_SET_LINE_CONTROL BtPort2 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
27 0.00000531 Pde_reader v3_1 IOCTL_SERIAL_SET_CHAR BtPort2 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:0 XOFF:0
28 0.00000475 Pde_reader v3_1 IOCTL_SERIAL_SET_HANDFLOW BtPort2 SUCCESS Shake:1 Replace:40 XonLimit:8192 XoffLimit:2048
29 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_GET_BAUD_RATE BtPort2 SUCCESS
30 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_GET_LINE_CONTROL BtPort2 SUCCESS
31 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_GET_CHARS BtPort2 SUCCESS
32 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_GET_HANDFLOW BtPort2 SUCCESS
33 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_GET_BAUD_RATE BtPort2 SUCCESS
34 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_GET_LINE_CONTROL BtPort2 SUCCESS
35 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_CHARS BtPort2 SUCCESS
36 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_GET_HANDFLOW BtPort2 SUCCESS
37 0.00000615 Pde_reader v3_1 IOCTL_SERIAL_SET_BAUD_RATE BtPort2 SUCCESS Rate: 57600
38 0.00001090 Pde_reader v3_1 IOCTL_SERIAL_CLR_RTS BtPort2 SUCCESS
39 0.00000978 Pde_reader v3_1 IOCTL_SERIAL_CLR_DTR BtPort2 SUCCESS
40 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_SET_LINE_CONTROL BtPort2 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
41 0.00000531 Pde_reader v3_1 IOCTL_SERIAL_SET_CHAR BtPort2 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:0 XOFF:0
42 0.00000950 Pde_reader v3_1 IOCTL_SERIAL_SET_HANDFLOW BtPort2 SUCCESS Shake:0 Replace:80000000 XonLimit:8192 XoffLimit:2048
43 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_TIMEOUTS BtPort2 SUCCESS
44 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_SET_TIMEOUTS BtPort2 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:-1172264056


45 0.00006258 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
46 0.00008381 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
47 0.00008381 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
48 0.00035982 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
49 0.00008688 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
50 0.00008632 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
51 0.00008549 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
52 0.00008800 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
53 0.00008521 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
54 0.00008716 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
55 0.00008800 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
56 0.00001425 Pde_reader v3_1 IOCTL_SERIAL_SET_WAIT_MASK BtPort2 SUCCESS Mask: RXCHAR BRK ERR
57 0.00000419 Pde_reader v3_1 IRP_MJ_CLEANUP BtPort2 SUCCESS
58 0.00008046 Pde_reader v3_1 IRP_MJ_CLOSE BtPort2 SUCCESS

[garyhgaryh]

Ok, analyzing the data I collected, it seems that with the bluetooth connection, the procede reader software writes to the com port 11 times before it quits:

45 0.00006258 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
46 0.00008381 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
47 0.00008381 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
48 0.00035982 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
49 0.00008688 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
50 0.00008632 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
51 0.00008549 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
52 0.00008800 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
53 0.00008521 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
54 0.00008716 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .
55 0.00008800 Pde_reader v3_1 IRP_MJ_WRITE BtPort2 SUCCESS Length 1: .

On the wire connection, there seems to be some kind of communication between the two devices since you see the read/write request:

45 0.00002822 Pde_reader v3_1 IRP_MJ_WRITE Serial0 SUCCESS Length 1: .
46 0.00000447 Pde_reader v3_1 IOCTL_SERIAL_GET_COMMSTATUS Serial0 SUCCESS
47 0.00312330 Pde_reader v3_1 IOCTL_SERIAL_WAIT_ON_MASK Serial0 SUCCESS
48 0.00000587 Pde_reader v3_1 IRP_MJ_READ Serial0 SUCCESS Length 1: .
49 0.00002486 Pde_reader v3_1 IRP_MJ_WRITE Serial0 SUCCESS Length 3: ...
50 0.00000503 Pde_reader v3_1 IOCTL_SERIAL_GET_COMMSTATUS Serial0 SUCCESS
51 0.00000587 Pde_reader v3_1 IOCTL_SERIAL_WAIT_ON_MASK Serial0 SUCCESS
52 0.00000251 Pde_reader v3_1 IOCTL_SERIAL_GET_COMMSTATUS Serial0 SUCCESS
53 0.24998065 Pde_reader v3_1 IOCTL_SERIAL_WAIT_ON_MASK Serial0 SUCCESS
54 0.00000670 Pde_reader v3_1 IRP_MJ_READ Serial0 SUCCESS Length 7: ...eg..
55 0.00000615 Pde_reader v3_1 IRP_MJ_READ Serial0 SUCCESS Length 0:
56 0.00003464 Pde_reader v3_1 IRP_MJ_WRITE Serial0 SUCCESS Length 6: ......
57 0.00000447 Pde_reader v3_1 IOCTL_SERIAL_GET_COMMSTATUS Serial0 SUCCESS
58 0.00000587 Pde_reader v3_1 IOCTL_SERIAL_WAIT_ON_MASK Serial0 SUCCESS

filtering out the ioctl_* request:

45 0.00002822 Pde_reader v3_1 IRP_MJ_WRITE Serial0 SUCCESS Length 1: .
48 0.00000587 Pde_reader v3_1 IRP_MJ_READ Serial0 SUCCESS Length 1: .
49 0.00002486 Pde_reader v3_1 IRP_MJ_WRITE Serial0 SUCCESS Length 3: ...
54 0.00000670 Pde_reader v3_1 IRP_MJ_READ Serial0 SUCCESS Length 7: ...eg..
55 0.00000615 Pde_reader v3_1 IRP_MJ_READ Serial0 SUCCESS Length 0:
56 0.00003464 Pde_reader v3_1 IRP_MJ_WRITE Serial0 SUCCESS Length 6: ......

I pulled the iogear serial bluetooth adapter from the procede and logged the serial connection (remember, the iogear device is not connected to anything via the db9 connector). The logs look identical. Its as if I'm not even connected to the procede device in the previous logs.

I know the serial bluetooth adapter works. I tested it with two hyperterminals connected via the serial bluetooth device and all is good. It just doesn't work with the procede for some reason.

Gary

[zenmaster]

Couple of things the: 301 needs to be in slave mode.
You may have to force DSR, DTR and CD to high and wire RTS to CTS (NULL-modem according to this). If the logger is set to hex mode, it should show the actual octets going back and forth.

[HighVoltage]

43 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_TIMEOUTS BtPort2 SUCCESS
44 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_SET_TIMEOUTS BtPort2 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:-1172264056

For some reason it is returning a very large long value (not negative). It is probably using an unsigned value that is getting (mis)interpreted as a signed (2s comp) value by Portman using %d instead of %u in the console (printf) output. In this instance I believe it is sending 0xBA20AB88 , which is +3122703240 but using %d would be shown as 0x..FBA20AB88 or -1172264056. Whoever wrote Portman probably never expected such a large value, and frankly, why would they? It is huge.

Something else to try in all of this is to monitor the serial comm between the GBS301 and the procede while the app is trying to establish communications. This can be helpful to determine if/how much of the data is making its way across and also at what rate(s). Just use a pair of diodes to tap onto the RX and TX (anodes), tie the cathodes together and run that to the RX of another serial port.

Originally Posted by zenmaster

Simply that there is no noticeable delay from measurement to presentation of an actively changing value (RPM, TPS, boost, speed, etc).

I haven't measured these, and don't know if it's push or pull. I do know that Eugen found (not surprisingly) the back-to-back Sena solution to be a little too slow for real-time (presumably real-time delay would be doubled).

I think I now understand what you are trying to communicate as real-time. There is some kind of visual display that is relating the data from the Procede. So for instance you push the throttle and then see RPMs change on the screen. I would guess that most consumer bluetooth 1.1 solutions are more on the order of 100ms to gather and push across. That 1/10 of a second is enough to start noticing a differential between the screen and the event. The serial baud rate will play a big role in reducing the lag between the event and the display. This is one part of the equation in which the lag can be reduced by simply reducing the bit widths and therefore the time it takes to transmit the information.

My feeling at this point is that the problem is a compatibility issue with the Procede RS232 protocol that is being used to transfer the data. Specifically the timeout interval. How long does the app and/or the Procede wait before timing out? Is it user adjustable?

There is always going to some delay. In this case I would bet the Procede was given a timeout interval based on a bit width or two. The speed in which this particular bluetooth solution is able to gather and transmit the data may simply exceed this interval.

[garyhgaryh]

Originally Posted by zenmaster

Couple of things the: 301 needs to be in slave mode.
You may have to force DSR, DTR and CD to high and wire RTS to CTS (NULL-modem according to this). If the logger is set to hex mode, it should show the actual octets going back and forth.

The 301 is already in slave mode (see my prev post).

I already forced DSR, DTR, and CD together and wired RTS to CTS (see my prev post).

I did try hex mode last night and it's throwing FF to the procede.

I'm using a null modem adapter that came with the 301. I tried my 'experiment' with and without this adapter. Same result.

Any other ideas? Keep 'em coming..

Here's my bench setup. Excuse the mess.

[garyhgaryh]

I'll play with it some more later today... thanks for looking at the logs.
Makes sense what you say.
Keep the ideas coming...
Gary

Originally Posted by HighVoltage

43 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_TIMEOUTS BtPort2 SUCCESS
44 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_SET_TIMEOUTS BtPort2 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:-1172264056

For some reason it is returning a very large long value (not negative). It is probably using an unsigned value that is getting (mis)interpreted as a signed (2s comp) value by Portman using %d instead of %u in the console (printf) output. In this instance I believe it is sending 0xBA20AB88 , which is +3122703240 but using %d would be shown as 0x..FBA20AB88 or -1172264056. Whoever wrote Portman probably never expected such a large value, and frankly, why would they? It is huge.

Something else to try in all of this is to monitor the serial comm between the GBS301 and the procede while the app is trying to establish communications. This can be helpful to determine if/how much of the data is making its way across and also at what rate(s). Just use a pair of diodes to tap onto the RX and TX (anodes), tie the cathodes together and run that to the RX of another serial port.




I think I now understand what you are trying to communicate as real-time. There is some kind of visual display that is relating the data from the Procede. So for instance you push the throttle and then see RPMs change on the screen. I would guess that most consumer bluetooth 1.1 solutions are more on the order of 100ms to gather and push across. That 1/10 of a second is enough to start noticing a differential between the screen and the event. The serial baud rate will play a big role in reducing the lag between the event and the display. This is one part of the equation in which the lag can be reduced by simply reducing the bit widths and therefore the time it takes to transmit the information.

My feeling at this point is that the problem is a compatibility issue with the Procede RS232 protocol that is being used to transfer the data. Specifically the timeout interval. How long does the app and/or the Procede wait before timing out? Is it user adjustable?

There is always going to some delay. In this case I would bet the Procede was given a timeout interval based on a bit width or two. The speed in which this particular bluetooth solution is able to gather and transmit the data may simply exceed this interval.

[zenmaster]

Originally Posted by HighVoltage

43 0.00000196 Pde_reader v3_1 IOCTL_SERIAL_GET_TIMEOUTS BtPort2 SUCCESS
44 0.00000168 Pde_reader v3_1 IOCTL_SERIAL_SET_TIMEOUTS BtPort2 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:-1172264056

For some reason it is returning a very large long value (not negative). It is probably using an unsigned value that is getting (mis)interpreted as a signed (2s comp) value by Portman using %d instead of %u in the console (printf) output. In this instance I believe it is sending 0xBA20AB88 , which is +3122703240 but using %d would be shown as 0x..FBA20AB88 or -1172264056. Whoever wrote Portman probably never expected such a large value, and frankly, why would they? It is huge.

According to this:

RI = ReadIntervalTimeout
RM = ReadTotalTimeoutMultiplier
RC = ReadTotalTimeoutConstant
WM = WriteTotalTimeoutMultiplier
WC = WriteTotalTimeoutConstant

They're all unsigned 32bit.

Originally Posted by HighVoltage

I think I now understand what you are trying to communicate as real-time. There is some kind of visual display that is relating the data from the Procede. So for instance you push the throttle and then see RPMs change on the screen. I would guess that most consumer bluetooth 1.1 solutions are more on the order of 100ms to gather and push across. That 1/10 of a second is enough to start noticing a differential between the screen and the event. The serial baud rate will play a big role in reducing the lag between the event and the display. This is one part of the equation in which the lag can be reduced by simply reducing the bit widths and therefore the time it takes to transmit the information.

Agreed, if the frame is long and has to be completely read before displayed.

Originally Posted by HighVoltage

My feeling at this point is that the problem is a compatibility issue with the Procede RS232 protocol that is being used to transfer the data. Specifically the timeout interval. How long does the app and/or the Procede wait before timing out? Is it user adjustable?

There is always going to some delay. In this case I would bet the Procede was given a timeout interval based on a bit width or two. The speed in which this particular bluetooth solution is able to gather and transmit the data may simply exceed this interval.

I'll take a look at this tonight.

OK, just briefly looking at it, for some reason, the Broacom stack wants to use XON/XOFF flow control. But the Procede does not use this method. Does not seem that any flow control is used. The IO operation is probably timing out waiting for the software flow control signal. I think we need to figure out how to turn off the software flow control.

[HighVoltage]

This is interesting, in the Bluetooth log...

28 0.00000475 Pde_reader v3_1 IOCTL_SERIAL_SET_HANDFLOW BtPort2 SUCCESS Shake:1 Replace:40 XonLimit:8192 XoffLimit:2048
....
42 0.00000950 Pde_reader v3_1 IOCTL_SERIAL_SET_HANDFLOW BtPort2 SUCCESS Shake:0 Replace:80000000 XonLimit:8192 XoffLimit:2048

For reference:
XonLim: Specifies the minimum number of bytes allowed in the input buffer before the XON character is sent.
XoffLim: Specifies the maximum number of bytes allowed in the input buffer before the XOFF character is sent. The maximum number of bytes allowed is calculated by subtracting this value from the size, in bytes, of the input buffer.

Curious why these are being set if software flow control is disabled. Is it what is being used between the bluetooth stacks?

Side note:
I believe if fTXContinueOnXoff is true the flag shown up in Replace will be set.

typedef struct _SERIAL_HANDFLOW {
   ULONG ControlHandShake;
   ULONG FlowReplace;
   LONG XonLimit;
   LONG XoffLimit;
   } SERIAL_HANDFLOW,*PSERIAL_HANDFLOW;

#define SERIAL_DTR_MASK           ((ULONG)0x03)
#define SERIAL_DTR_CONTROL        ((ULONG)0x01)
#define SERIAL_DTR_HANDSHAKE      ((ULONG)0x02)
#define SERIAL_CTS_HANDSHAKE      ((ULONG)0x08)
#define SERIAL_DSR_HANDSHAKE      ((ULONG)0x10)
#define SERIAL_DCD_HANDSHAKE      ((ULONG)0x20)
#define SERIAL_OUT_HANDSHAKEMASK  ((ULONG)0x38)
#define SERIAL_DSR_SENSITIVITY    ((ULONG)0x40)
#define SERIAL_ERROR_ABORT        ((ULONG)0x80000000)
#define SERIAL_CONTROL_INVALID    ((ULONG)0x7fffff84)

#define SERIAL_AUTO_TRANSMIT      ((ULONG)0x01)
#define SERIAL_AUTO_RECEIVE       ((ULONG)0x02)
#define SERIAL_ERROR_CHAR         ((ULONG)0x04)
#define SERIAL_NULL_STRIPPING     ((ULONG)0x08)
#define SERIAL_BREAK_CHAR         ((ULONG)0x10)
#define SERIAL_RTS_MASK           ((ULONG)0xc0)
#define SERIAL_RTS_CONTROL        ((ULONG)0x40)
#define SERIAL_RTS_HANDSHAKE      ((ULONG)0x80)
#define SERIAL_TRANSMIT_TOGGLE    ((ULONG)0xc0)
 #define SERIAL_XOFF_CONTINUE      ((ULONG)0x80000000)
#define SERIAL_FLOW_INVALID       ((ULONG)0x7fffff20)

[HighVoltage]

Originally Posted by zenmaster

According to this:

RI = ReadIntervalTimeout
RM = ReadTotalTimeoutMultiplier
RC = ReadTotalTimeoutConstant
WM = WriteTotalTimeoutMultiplier
WC = WriteTotalTimeoutConstant

They're all unsigned 32bit.

Right. So I will bet someone simply put %d instead of %u. Common mistake.