Sale ends todayGet 30% off any course (excluding packages)
Ends in --- --- ---
Discuss all things tuning in this section. News, products, problems and results.
looking to set up a basic data logging set up, starting with a Haltech Elite 1000 ECU.
the obvious option is a racepak logging dash and log over CAN the information being input into the haltech. (cost effective vs racepak sensor modules)
my concern is rapidly changing data such as RPM and oil pressure require a high refresh rate so my question is:
What refresh rate does haltech broad cast over CAN? and secondly what frequency have people found to be optimal for common types of data? (ie coolant temp = 1Hz but rpm requires 50Hz etc)
if this is documented by haltech some where i apologize i have not been able to find this information.
The answer to your question is that the transmit rate is easily capable of doing what you want as we're using a MoTeC C125 dasg to log from the Elite in our Z, however I also couldn't find any info on the transmit rate. I rang Haltech to get a proper answer and the transmit rate varies depending on the channel. Fast changing data such as rpm and pressures is transmit at 50Hz. I've included the CAN broadcast document as an attachment.
I usually log slow moving channels like temperatures at 1-2 Hz and fast moving data like rpm and MAP at 20-50 Hz depending on my logging memory. The reality is that 20-25 Hz will usually suffice for most of what you'll want to analyse.
It isn't an issue of refresh rate however bitrate. For example older CAN ran at 500bit and 'high speed' CAN runs at 1000bits/sec (1 megabit). To that end the resolution is theoretically infinite provided the ECU doesn't downsample and you can cram the data you need into 1 megabit per second.
I think you mean 500kbit and 1000kb (1Mb), as in 500,000 bits per second, and 1,000,000 bits per second.
But the bitrate isn't the issue here, providing the bus isn't hugely full, which on an aftermarket ecu setup is usually the case. The issue is how often the Haltech sends out a data packet with an updated RPM value. If it does this 50 times per second, then that is the maximum frequency any other device is going to be able to log that value at... You could set another device to log RPM at, say 200Hz, but since the RPM value is only being updated by new information on the network at 50Hz, the device logging it at 200Hz will just record four of the same RPM values in a row (200/50 = 4).
in hindsight, i am thinking, if you want protection, it will be best to wire the sensors to the haltech itself, as it will "react" fastest with this and the if you have max out your I/O there is the expansion box that may end up costing less buy time you have added sensors. This way the log is now a overview of what happened and not not the base of your protection. The ecu get all its data in the fastest way it can, with the protection you setup and you all the data you need at the best speed the ecu will log over CAN. The question in mine mind now is, how fast is the ecu reading the sensors that are analog and does haltech give the I/O expansion box a higher priority? (thinking out loud).
Word, Zac, late night and answering the question of 'how fast does CAN refresh' to a myriad of people had me a bit confused.