Page 1 of 1

[SOLVED] drain CAN bus for specific time period

Posted: Fri Mar 09, 2018 11:46 pm
by thoraxe
I've got a number of posts on this topic or related to this topic, so just check my profile.

Haltech ECU + WBo2
AEM CD7 dashboard
RCP Mk2, firmware 2.13.0

I have a number of the important CAN channels from my ECU mapped in the RCP for logging purposes.

Here's my current script: ... edce87311b

The problem:
If I move the sendGPS/IMU function calls out of the drain (repeat/until) loop, it seems like they basically never happen. My dashboard doesn't seem to ever get GPS data from the RCP. With them inside the loop (as pictured), it seems like some of the channel data ends up getting transmitted very, very slowly. I think because it's actually transmitting GPS data for every single channel it pulled off the buffer.

What I really want:
I want to retransmit a specific subset of CAN channels/messages without having to essentially rebuild the CAN mapping again. In other words, I know that I want to retransmit channel 864, 865, and several others. I've already mapped this data in the RaceCapture app.

I don't want to have to basically re-map it in Lua just to be able to transmit it.

Is there some way to do the following (pseudocode):

Code: Select all

function onTick()
txcan ( rxcan(some specific can message / channel) )
txcan ( rxcan(some other specific message / channel) )
I know I can grab mapped channels virtually (getChannel), but my dash is looking for Haltech formatted messages already, so I'd actually have to re-un-format the mapped channel into the Haltech data format, assemble a message from the mapped channels, and then transmit it.

That seems like an atrocious amount of work.

My other and uglier and more physically intensive option is to abandon using the RCP for retransmit and just homerun another CAN cable from the ECU all the way to the dash's other CAN channel. So basically I'd only be sending GPS data from the RCP to the AEM CD7, and the CD7 would pick up all of the other vehicle data directly from the CAN bus.


Posted: Sat Mar 10, 2018 8:38 pm
by brentp
What seems to be happening is that you're receiving data faster than the rxCAN loop can process it, not allowing it to drop into the txGPS / txIMU portion.

What I would do is have it break out of the rxCAN() loop if a certain amount of time has elapsed, so the txGPS and txIMU messages can be handled, then let the onTick() function exit, and let the system call onTick() again, later, to start the process again.

In the past a simple way was to just let rxCAN() drop through if more than N number of messages was received.

If you want to do a time based timeout, you can use the getUptime() function to figure out the timeout: ... time.28.29

Hope this helps,

Posted: Fri Mar 16, 2018 7:16 pm
by thoraxe
Yes, this did help. ... edce87311b

This includes a revised version of the script using the uptime to drain for a specific time period.

Later I made a small edit to add a configuration variable (drain_period) and then changed the exit to be dependent on the time period defined.

Ideally I'd like to make this a function of the tickrate (to ensure a fixed drain window). I'll post separately for that.

Posted: Wed Mar 21, 2018 1:52 am
by brentp
Glad the suggestion worked for you!