I know my Mustang is transmitting catalyst temperature information on OBD PID 013C because I can see it in another app using a different OBDII dongle (GoPoint BT1). However, when I set up an OBDII channel with PID 60 (decimal value of 3C hex), the log says it's being squelched because of excessive timeouts. So what is the timeout setting? The information from the other app is that the response time is over 400ms.
Also, if I configure a CAN channel on the device using a computer over USB, should I be able to see data with the iOS1.8.0 app? I'm not, but I don't know if it's because the CAN channel is not configured correctly or the app just doesn't see it.
Timeout period for squelching OBDII channel?
-
dewittpayne
- Posts: 67
- Joined: Sun Dec 11, 2016 1:07 am
our OBDII timeout is 300ms, which would explain why you're seeing that effect. 300ms is an eternity for computers and electronics, so it's quite surprising your ECU would take 400ms to return a value. :-/
As you probably know - but worth mentioning for the greater audience - since OBDII channels must be queried sequentially, every time it queries that channel, the OBDII sequencer engine is blocked until that query is complete.
We can probably increase the timeout to 500ms safely, would need to test it a bit.
Regarding configuring channels and dashboard mode:
Streaming data for the dashboard / local logging is independent of the configuration views. So yes, you could set things up on the desktop app, and then simply view it on the iOS device.
As you probably know - but worth mentioning for the greater audience - since OBDII channels must be queried sequentially, every time it queries that channel, the OBDII sequencer engine is blocked until that query is complete.
We can probably increase the timeout to 500ms safely, would need to test it a bit.
Regarding configuring channels and dashboard mode:
Streaming data for the dashboard / local logging is independent of the configuration views. So yes, you could set things up on the desktop app, and then simply view it on the iOS device.
-
dewittpayne
- Posts: 67
- Joined: Sun Dec 11, 2016 1:07 am
The GoPoint BT1 supports parallel requests, so response time is less of an issue with an app that also supports parallel requests. I don't really need it, but since I knew it was available, I thought I'd test it. If I could move all the fast stuff to CAN, then slow response on OBDII would probably be tolerable.
It's important to understand that the The OBDII SAE standard prescribes that only one channel can be requested at a time.
What they're likely doing with the 'parallel requests' is that the app requests multiple PIDs across the BT link, then the module requests those PIDs sequentially and returns the results in a batch- this saves the back and forth across the bluetooth link. However, the ECU still needs to receive it's queries one at a time, and a slow PID will slow down the entire chain of requests.
RaceCapture optimizes this in another way, where the configuration is made in advance, and all of the querying is done as close to the metal as possible (the ECU), and the current data is broadcast at a regular interval to the app.
Hope this helps,
What they're likely doing with the 'parallel requests' is that the app requests multiple PIDs across the BT link, then the module requests those PIDs sequentially and returns the results in a batch- this saves the back and forth across the bluetooth link. However, the ECU still needs to receive it's queries one at a time, and a slow PID will slow down the entire chain of requests.
RaceCapture optimizes this in another way, where the configuration is made in advance, and all of the querying is done as close to the metal as possible (the ECU), and the current data is broadcast at a regular interval to the app.
Hope this helps,