RegisterSearchFAQMemberlistUsergroupsLog in
Reply to topic Page 1 of 1
Timeout period for squelching OBDII channel?
Author Message
Reply with quote
Post Timeout period for squelching OBDII channel? 
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.

View user's profile Send private message
Reply with quote
Post  
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.

View user's profile Send private message Send e-mail
Reply with quote
Post  
Tracking here: https://github.com/autosportlabs/RaceCapture-Pro_firmware/issues/922


_________________
Brent Picasso
CEO and Founder, Autosport Labs
Facebook | Twitter
View user's profile Send private message Send e-mail
Reply with quote
Post  
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.

View user's profile Send private message
Reply with quote
Post  
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,


_________________
Brent Picasso
CEO and Founder, Autosport Labs
Facebook | Twitter
View user's profile Send private message Send e-mail
Display posts from previous:
Reply to topic Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum