"sendCommand" returns "NO DATA" for "getSupportedPIDs" for ELM327 (BLEManager)

[SOGAPPS]

Describe the bug
The "sendCommand" function for ELM327 (BLEManager) returns "NO DATA" most times. In this case it's returning no data for "getSupportedPIDs" function.

To Reproduce
Steps to reproduce the behavior:

1. Run SwiftOBD2App on Xcode
2. When app loads, on main page click start to connect to car "ECU"
3. Xcode Log returns "NO DATA"

Expected behavior
When I send code "0101" for Supported PIDs [01-20], we should get the cars supported pids from [01-20].

Smartphone (please complete the following information):

• Device: [e.g. iPhone SE]
• OS: [e.g. iOS 17.4.1]

Additional context
Current Test Car: 2016 BMW 328i
Note: The command works fine in a separate project directly calling ".writeValue(data, for: characteristic, type: .withResponse)".

The returned OBD2 Code is sent to our custom cloud-function parser that converts it to readable value. Returned Log below:

Service UUID: FFF0
Write Characteristic UUID: FFF1
Characteristic's value subscribed
Subscribed. Notification has begun for: FFF1
Message sent
Received OBD-II Data: 41 00 BE 3F A8 13 

Received OBD-II Data: 41 00 98 18 80 11 

Cloud function response: ["pidInfo": {
    bytes = 4;
    description = "PIDs supported 00-20";
    max = 0;
    min = 0;
    mode = 01;
    name = pidsupp0;
    pid = 00;
    unit = "Bit Encoded";
}, "OBD2Response": {
    mode = 41;
    name = pidsupp0;
    pid = 00;
    unit = "Bit Encoded";
    value = (1, 0, 1, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 1);
}]

[kkonteh97]

hey I not really sure why 0101 results are inconsistent. the only time I have had issues with it is when using a wi-fi adapted. I will investigate to try to find out what the issue is thanks for bringing it up.

[calamaro]

Same issue here:

`Sending command: AT SH 7E0
Response: ["OK"]

Getting supported PIDs for 0100
Sending command: 0100
Response: ["NO DATA"]

Getting supported PIDs for 0120
Sending command: 0120
Response: ["NO DATA"]

Getting supported PIDs for 0140
Sending command: 0140
Response: ["NO DATA"]

Getting supported PIDs for 0600
Sending command: 0600
Response: ["NO DATA"]

Getting supported PIDs for 0620
Sending command: 0620
Response: ["NO DATA"]

Getting supported PIDs for 0640
Sending command: 0640
Response: ["NO DATA"]

Getting supported PIDs for 0660
Sending command: 0660
Response: ["NO DATA"]

Getting supported PIDs for 0680
Sending command: 0680
Response: ["NO DATA"]

Getting supported PIDs for 06A0
Sending command: 06A0
Response: ["NO DATA"]

Getting supported PIDs for 0900
Sending command: 0900
Response: ["NO DATA"]

Getting supported PIDs for 0100
Sending command: 0100
Response: ["NO DATA"]

Getting supported PIDs for 0120
Sending command: 0120
Response: ["NO DATA"]

Getting supported PIDs for 0140
Sending command: 0140
Response: ["NO DATA"]

Getting supported PIDs for 0600
Sending command: 0600
Response: ["NO DATA"]

Getting supported PIDs for 0620
Sending command: 0620
Response: ["NO DATA"]

Getting supported PIDs for 0640
Sending command: 0640
Response: ["NO DATA"]

Getting supported PIDs for 0660
Sending command: 0660
Response: ["NO DATA"]

Getting supported PIDs for 0680
Sending command: 0680
Response: ["NO DATA"]

Getting supported PIDs for 06A0
Sending command: 06A0
Response: ["NO DATA"]

Getting supported PIDs for 0900
Sending command: 0900
Response: ["NO DATA"]`

[SOGAPPS]

Thanks @calamaro . We are also getting the same logs provided.

@kkonteh97
Hope this helps, we started by comparing our separate working project "TestAPP-A" to the "SwiftOBD2".
Goal: To see if the difference in the way the two apps handle communication with the OBD-II adapter might be the cause of the issue. Here's a breakdown of the key differences:

sendMessageCompletion vs. Core Bluetooth Delegate Methods:

• In the "SwiftOBD2" app, it appears to use a custom completion handler (sendMessageCompletion) to handle responses from the OBD-II adapter.
• In the "TestAPP-A" app that works, we use the Core Bluetooth delegate methods (didWriteValueFor and didUpdateNotificationStateFor) to handle communication with the OBD-II adapter.

Handling Responses:

• "SwiftOBD2" app relies on the sendMessageCompletion closure to handle responses received from the adapter.
• "TestAPP-A" app that works handles responses directly within the didWriteValueFor delegate method.

Timeout

Code: Line 295 in "bleManger" return try await Timeout(seconds: 3) {}
We also tried increasing the time out to see if the duration is too short. Thinking it may not allow enough time for the peripheral to process the command and send a response. This didn't resolve the issue. [Changed from 3s to 6s]

ascii vs utf8

Code: Line 290 in "bleManger" let data = "\(command)\r".data(using: .ascii)

• For character encoding "SwiftOBD2" app uses ".ascii" to convert the command string to data. But uses the ".utf8" to convert the sent OBD2 response.
• For character encoding "TestAPP-A" app uses ". utf8" to convert the command string to data.

[kkonteh97]

I believe I know what the issues is let added some changes to the dev branch and you guys can test it out

[kkonteh97]

I commented out the setHeader function in setHeader in the elm327 file, should fix it. let me know if It works. it's on the debug branch.

[kkonteh97]

Thanks @calamaro . We are also getting the same logs provided.

@kkonteh97 Hope this helps, we started by comparing our separate working project "TestAPP-A" to the "SwiftOBD2". Goal: To see if the difference in the way the two apps handle communication with the OBD-II adapter might be the cause of the issue. Here's a breakdown of the key differences:

sendMessageCompletion vs. Core Bluetooth Delegate Methods:

• In the "SwiftOBD2" app, it appears to use a custom completion handler (sendMessageCompletion) to handle responses from the OBD-II adapter.
• In the "TestAPP-A" app that works, we use the Core Bluetooth delegate methods (didWriteValueFor and didUpdateNotificationStateFor) to handle communication with the OBD-II adapter.

Handling Responses:

• "SwiftOBD2" app relies on the sendMessageCompletion closure to handle responses received from the adapter.
• "TestAPP-A" app that works handles responses directly within the didWriteValueFor delegate method.

Timeout

Code: Line 295 in "bleManger" return try await Timeout(seconds: 3) {} We also tried increasing the time out to see if the duration is too short. Thinking it may not allow enough time for the peripheral to process the command and send a response. This didn't resolve the issue. [Changed from 3s to 6s]

ascii vs utf8

Code: Line 290 in "bleManger" let data = "\(command)\r".data(using: .ascii)

• For character encoding "SwiftOBD2" app uses ".ascii" to convert the command string to data. But uses the ".utf8" to convert the sent OBD2 response.
• For character encoding "TestAPP-A" app uses ". utf8" to convert the command string to data.

I set the header for the ecu to filter out messages coming from the engine. but my current method setting the header always to 7E0 does not work on all cars.

[calamaro]

I commented out the setHeader function in setHeader in the elm327 file, should fix it. let me know if It works. it's on the debug branch.

Yes, it's working now

[SOGAPPS]

I commented out the setHeader function in setHeader in the elm327 file, should fix it. let me know if It works. it's on the debug branch.

@kkonteh97 Thanks, it works now.
If you don't mind me asking again. Why are you setting a predefined value of "7E0" ~ "AT SH 7E0" for ECUHeader.ENGINE

[kkonteh97]

I commented out the setHeader function in setHeader in the elm327 file, should fix it. let me know if It works. it's on the debug branch.

@kkonteh97 Thanks, it works now. If you don't mind me asking again. Why are you setting a predefined value of "7E0" ~ "AT SH 7E0" for ECUHeader.ENGINE

I got that from the elm327 manual, it worked in filtering out engine responses for most cars but not all. I need to figure out a way to map the response headers, then send the engine header with AT SH.