Bluetooth connection speeds higher than 9600

[Stinky]

Hi Matt, and everyone else...
I'll be honest, I haven't done a whole lot of searching on this so flame me if I deserve it.

I'm playing around with using a Roving Networks rs-41 bluetooth module as the basis for a dedicated bluetooth consult adapter. There appear to be two connection speed parameters of concern in this case.
a) the speed of the UART on the bluetooth that actually talks to the ECU (9600baud)
b) the speed of the bluetooth connection between the bluetooth module and the pc/phone

At this time I am able to connect to the ecu using Nistune and the bluetooth module. However, I'm noticing a pretty decent speed difference between a wired connection (blazt.biz USB cable) and the bluetooth. I believe the reason for the difference may be that the bluetooth connection to the pc is being limited by Nistune to only 9600. I wont pretend to know much about how the bluetooth connection is handled but I'm thinking that by the time all of the error correction and other overhead is taken care of the actual data throughput ends up being significantly slower than 9600 baud. Does that sound reasonable?

On to my question. Would it be possible to modify Nistune to allow the bluetooth to connect at a higher speed, say 115200? The local connection to the ecu is programmed to 9600 on the bluetooth module so I believe changing the connection speed in Nistune shouldnt create a problem unless maybe the commands sent from Nistune become too fast to handle on the ecu side and overflow any buffer in the bluetooth.

Thoughts?

[Matt]

It may be latency and packet sizes affecting things

Nistune uses small packet sizes and continuous command/response. If there is extra latency due to bluetooth then the delay between each command/response increases slowing down the comms

How does it react in stream mode where you only have one directional data from the ECU once triggered?

[Stinky]

Ah, I see.

As far as I can tell, it's fine in streaming mode. The log viewer shows nice smooth graphs in streaming mode but in tuner mode the graphs are stepped quite a bit.

The packet sizing and latency do make sense. I'll see if I can find any settings on the bluetooth module that might help speed things up.

Thanks!

[RomChip200]

I gave up trying to get Nistune working over Bluetooth for Consult and Innovate LC1s, trying many RS232-BT dongles.
It's just not reliable. Bluetooth extra latencies just jeopardize the link.

[Matt]

It would only be good for one way directional streaming where the latencies are not such an issue. However for bidirectional communication using small packets (remembering consult buffer sizes are around 16-20 bytes) we hit a technical wall

[skyline_stu]

The problem that causes the latency is related to the way Bluetooth and Nistune operate.

Think about this... Bluetooth modules run by
Host sends data -> slave
Slave sends data -> host

When communications are in operation, the bluetooth module can't transmit and receive at the same time, and unfortunatly there is delay (latency) while the module changes from Tx Mode to Rx mode. This causes a big problem as Nistune constantly sends data out and gets its reply back. On some modules this can be 20ms or longer. There is also processing delays on the modules themselves and hence we get slower data transfers.

I've tried a dual module arangement (one bluetooth for Tx, one for Rx) and this helped out somewhat, but there was still some delays due to module processing overheads.

Unfortunatly, at this time most of the CSR based chipsets have this 'problem'.

Some of the more nasty modules [el cheapo's] have a delay of over 100ms from the data being sent to it being available at the output of the slave module.

You'll find in Stream mode things work really great, as the PC is not sending out packets of data like Tuner mode.

This has been a major 'thorn in my side' with the BlueSult interface.

I've also tried it with my Hi-speed consult f/w updates on the R33's @ 19.2k. The CSR chipset processing delay still was present and slowed things down.

Stinky, from what I've found there is a baud rate limit on the ECU too. Things get too unreliable at over 19.2k or aren't even recieved by the ECU. It appears that the ECU's signal filtering [well on the r33 anyway] starts to become overwhelmed and the clock pulse doesn't come through to the processor. There's also the firmware which gets hung up at > 19.2k most of the time. Consider that at 19.2k the clock running at just over 307kHz. At 38400 it's 614kHz !! (baud clock needs to be 16x data rate.)

This really chews into the processor's time to do other more important things, like run the engine, as the serial routine uses lot's of interupts ! (Matt will know what I mean about this)

Even at 19.2k you need to drop the data clock from 12v to 5v for it to work reliably.

Stu

[RomChip200]

The problem that causes the latency is related to the way Bluetooth and Nistune operate.

Think about this... Bluetooth modules run by
Host sends data -> slave
Slave sends data -> host

When communications are in operation, the bluetooth module can't transmit and receive at the same time, and unfortunatly there is delay (latency) while the module changes from Tx Mode to Rx mode. This causes a big problem as Nistune constantly sends data out and gets its reply back. On some modules this can be 20ms or longer. There is also processing delays on the modules themselves and hence we get slower data transfers.

I've tried a dual module arangement (one bluetooth for Tx, one for Rx) and this helped out somewhat, but there was still some delays due to module processing overheads.

Unfortunatly, at this time most of the CSR based chipsets have this 'problem'.

Some of the more nasty modules [el cheapo's] have a delay of over 100ms from the data being sent to it being available at the output of the slave module.

You'll find in Stream mode things work really great, as the PC is not sending out packets of data like Tuner mode.

This has been a major 'thorn in my side' with the BlueSult interface.

I've also tried it with my Hi-speed consult f/w updates on the R33's @ 19.2k. The CSR chipset processing delay still was present and slowed things down.

Stinky, from what I've found there is a baud rate limit on the ECU too. Things get too unreliable at over 19.2k or aren't even recieved by the ECU. It appears that the ECU's signal filtering [well on the r33 anyway] starts to become overwhelmed and the clock pulse doesn't come through to the processor. There's also the firmware which gets hung up at > 19.2k most of the time. Consider that at 19.2k the clock running at just over 307kHz. At 38400 it's 614kHz !! (baud clock needs to be 16x data rate.)

This really chews into the processor's time to do other more important things, like run the engine, as the serial routine uses lot's of interupts ! (Matt will know what I mean about this)

Even at 19.2k you need to drop the data clock from 12v to 5v for it to work reliably.

Stu

I'm not sure it's the right explanation.
Consult works in a master-slave model (request --> answer), and BT should do the same as you mentioned above, so it should match ... but it doesn't in reality
It's not so simple.
I think there're 3 many reasons:
_as any air link, BT induces latencies (to go accross the BT stack and the BT hw IP itself)
_any BT stack and BT hw IP have FIFOs and some thresholds to start to transmit or to trigger the callback to the upper SW layer when bytes are received)
Consult has 1 byte Rx granularity and so, with a 8 bytes FIFO and threshold=8, it just doesn't work, you lose the link ....
Some BT chipsets allow to tune the FIFO thresholds but in most of the cases, it's not enough.
Some BT dongles also play with DTR, DSR, RTS or CTS to know when they need to start to transmit .... and in case of Consult, it just doesn't work that way. On top of that, hardware flow control becomes over-the-air messages in the case of BT.
I got the Parani SD100 working for BT link with Consult, but it's just not enough reliable, the link drops too often:
_Consult doesn't use flow control and here what happens when lacking it:
When hardware flow control is not being used, the Parani-SD clears the buffer to secure room for the
next data when the buffer becomes full. This can mean a loss of data may occur. As the transmission
data becomes large, the possibility of data loss becomes greater.
If Consult was using RTS/CTS, we would have more chances to get it working.

manual_parani_sd-v1.1.7.pdf

(1.51 MiB) Downloaded 266 times

Increasing baud rate over 9600 is meaningless as it has not been designed for this (neither ECU or the Consult interface).

[skyline_stu]

I'm not sure it's the right explanation.
Consult works in a master-slave model (request --> answer), and BT should do the same as you mentioned above, so it should match ... but it doesn't in reality
It's not so simple.
I think there're 3 many reasons:
_as any air link, BT induces latencies (to go accross the BT stack and the BT hw IP itself)
_any BT stack and BT hw IP have FIFOs and some thresholds to start to transmit or to trigger the callback to the upper SW layer when bytes are received)
Consult has 1 byte Rx granularity and so, with a 8 bytes FIFO and threshold=8, it just doesn't work, you lose the link ....
Some BT chipsets allow to tune the FIFO thresholds but in most of the cases, it's not enough.
Some BT dongles also play with DTR, DSR, RTS or CTS to know when they need to start to transmit .... and in case of Consult, it just doesn't work that way. On top of that, hardware flow control becomes over-the-air messages in the case of BT.
I got the Parani SD100 working for BT link with Consult, but it's just not enough reliable, the link drops too often:
_Consult doesn't use flow control and here what happens when lacking it:
When hardware flow control is not being used, the Parani-SD clears the buffer to secure room for the
next data when the buffer becomes full. This can mean a loss of data may occur. As the transmission
data becomes large, the possibility of data loss becomes greater.
If Consult was using RTS/CTS, we would have more chances to get it working.

Increasing baud rate over 9600 is meaningless as it has not been designed for this (neither ECU or the Consult interface).

I should clarify things in a little more detail.
The BlueSult interface master is a combined USB serial port and BT module in hardware. It's not a conventional dongle.
The slave is a complete consult interface with the BT module onboard. I have complete control over serial functions at both ends.

I did quite a lot of testing with the BlueSult interface with many different modules after I was made aware of the latency problems. The biggest issue, even for single byte or a packet of data is that there is a delay from the PC Tx to the ECU Rx. And it works the other way round too. The BT modules have a processing latency issue either direction, so after we send a command, there will always be a delay for the round trip. If the latency is 20ms either way [assuming zero processing time in the ecu], the delay before the PC gets its reply is 40ms. This directly slows down the consult stream.

Go pop a scope or logic analyser onto the master Tx to slave Tx lines and have a look at the delays for the round trip. Same for the Rx lines.
Stream mode simply requests a stream of data back to the PC and the BT modules pump out the data. The BT module doesn't need to add in a longer delay to swap between Rx & Tx transmissions. There's still processing delays..

In tuner data is sent in packets of 5-20+ bytes and this swapover adds a huge overhead. I tried a messing with the fifo buffer on the CSR based modules. It didn't improve things, I didn't find I was loosing data though.

Maybe the Parani modules BT engine has the same issue as the CSR units with latency. Do you know what chipset is used? I noticed that it mentioned a SENA module in the PDF.

I'm aware of the RTS/CTS flow control, and the master BlueSult has a FIFO in the FTDI device. Biggest delay then was Rx/Tx swapover with bigger packets - your right about the OTA flow control messages - they added in MORE latency as processing time increased !!

Higher baud rates do make a big difference on the H8 processor. It's 25% quicker when the car is running and up to 50% faster when the engine is off. I suspect it's due to the ECU having more time to handle the serial routines rather than run the engine. I haven't had time to test it on the earlier CPU's, but I'm sure it should still work.

Running dual (4xBT modules) did improve things as there was a dedicated Tx/Rx channel, but the processing delay still affected throughput.
Stu