DIYEFI.org Forum

Your ADC example is exactly why telemetry is classified as Level 0, 1, 2, etc. To carry your example forward, say the raw ADC data is L0, and the filtered ADC number is L1. Set the log level to L1, and you get only the filtered ADC readings. So maybe the better approach than logging all the raw data, is to allow the user/tuner/coder to set the logging level to whatever is required for the task at hand. The catch is that various data need to be assigned an appropriate Level.

As for the timestamping, it doesn't need to be anything elaborate; i've often used a 16-bit millisecond timer as a timestamp. The important thing is to be able to determine the delta time between log entries, especially in an asynchronous log. Logging is a tertiary function at best, interrupts being primary and the main EMS program cycle being secondary. The scenario that's bitten me more than once is a dropped event. Say injector "on" duration is the parameter of interest. Dropped injector entries will throw the tuning calculations off, but will show up as a gap in a time plot of the data. Hope that makes sense.

That's exactly what is planned. The simply datalog thread was for exactly that, a simple datalog that is static over time :-)

Also available will be complex datalogs with masking so you can have ANY fields in and any fields out. This will be a very powerful tool IMO.

Fred.

This is the spec for the Autroinc SM4. We've used Autronics for the past 5 years on our Formula SAE team and theyve been pretty good but not perfect. The datalog stream is an example of this, its fixed and pretty basic - we had to use the exhaust back pressure input for oil pressure so we could log it with our ADL2.

//Data stream byte allocation definitions
#define start_string 0
#define packet_size 1
#define battery_voltage_l 2
#define battery_voltage_h 3
#define coolant_temp_l 4
#define coolant_temp_h 5
#define charge_temp_l 6
#define charge_temp_h 7
#define air_temp_l 8
#define air_temp_h 9
#define spare_speed_l 10
#define spare_speed_h 11
#define vehicle_speed_l 12
#define vehicle_speed_h 13
#define exh_back_pres_l 14
#define exh_back_pres_h 15
#define mani_pres_l 16
#define mani_pres_h 17
#define throttle_pos_l 18
#define throttle_pos_h 19
#define rpm_l 20
#define rpm_h 21
#define AFR_1 22
#define AFR_h 23
#define cam_angle1_l 24
#define cam_angle1_h 25
#define cam_angle2_l 26
#define cam_angle2_h 27
#define error1 28
#define error2 29
#define error3 30
#define error4 31
#define error5 32
#define error6 33
#define error7 34
#define error8 35
#define inject_pulse_width_l 36
#define inject_pulse_width_h 37
#define ingition_angle 38
#define knock_ret 39
#define checksum_l 40
#define checksum_h 41

I think you should be able to decode most of that. I dragged it straight out of my avr code that I wrote for the dash so excuse the format. As you can see most of the data is stored in 16 bit variables.

Things to note:
- we used exh back pressure as an oil pressure input
- the 'charge temp' is a value that the ecu calculates from the coolant temp and air temp, its supposed to represent the temp on the back of the valve i think
- the start byte is an ascii '$' which makes it easy to basic error checking (ie. if data = '$' then buffer position = 0)
- never used the checksum as we were only using it as a display so a bad packet every now and then wasnt a problem

Fred wrote:Agreed on the recreate thing, except that a large part of the logs purpose early on is to catch bugs in my code and that doing only level zero will get you double the work load (for the tuning author). Also, for example, if the ADCs are filtered then you need that filtered value at the very least.

I 100% agree on the time stamping being a good idea, but disagree that it is 100% required, remember that we are mostly trying to tune an engine, ie, we want to know what its current advance, dwell, AFR, load and RPM are so we can trim them to be correct.

Er, the "recreate" thing can really be a pain - in a minimal dataset, true - but it's nice to know not just what the fuel delivered was, but why (is it warmup enrich? accel enrich? after start?)... One of my biggest MS complaints is the logs being useless, and even people who know the code inside and out can't tell me what is happening with full logs.

Timestamping - would it help to send merely the time between data points? I guess it's the same amount of work, so wouldn't buy you anything - but certainly adding the numbers could be done offline to get absolute reference. Maybe just send the milliseconds number.

Yeah, it'll be a fine grained time stamp, something that gives a good measure between high speed logs.

I just read this whole thread again, there is lots of noob-ness esp by me, but lots of good info also.

Re the time stamps and delta times thing, I will do some math and figure out the best unit to use and add one in. I'm unsure whether to use a difference in the log, or a stamp and let the external stuff do the diffing. I hadn't thought about this for a while, but it should be straight forward to calculate. What if there hasn't been a log for a while? Perhaps just stamps are best, certainly easier and faster on the EMS side.

I'll post again once I've researched and documented this.

Useful posts re loggoing:

Dave's thread: viewtopic.php?f=8&t=1019

My recent post: viewtopic.php?p=12370#p12370

Fred.