[Donald-335i]

ok guys this is gonna be a pretty noob question..

i'm going to upgrade to 2.0 very shortly and very excited to datalog. but honstly i have no idea what to look for whats good whats bad etc,

if anyone can please help me thanks in advance

[LostMarine]

its easy. just started it today.. once you join the BIG boys club i can walk you through it


(BTW-your sig is uber-gay )

[scalbert]

You can start here using the BT interface.

http://www.hopesystemsinc.com/bmw_fats.asp

You can also use the following config file.

http://www.hopesystemsinc.com/BavTechLogFiles/

Edit: I beleive you are refering to the JB2 logging. However, BT provides siginificantly more and useful data.

[StartupJunkie]

Originally Posted by Donald-335i

ok guys this is gonna be a pretty noob question..

i'm going to upgrade to 2.0 very shortly and very excited to datalog. but honstly i have no idea what to look for whats good whats bad etc,

if anyone can please help me thanks in advance

What's the sampling rate if jb3 logging and can it log useful things like ignition advance (for knock detection), timing correction, engine temp, or actual throttle?

[scalbert]

Originally Posted by StartupJunkie

What's the sampling rate if jb3 logging and can it log useful things like ignition advance (for knock detection), timing correction, engine temp, or actual throttle?

Of course it can't but it still provides some insight. It, combined with the BT interface, will provide useful information for the JB crowd.

As for sampling rate, I do hope that is improved. Of the logs posted, it appears to be in the 1 - 2 Hz range which is not very good. IMO, it would have been better to not post logs showing such a poor sampling rate.

[Mike@N54Tuning.com]

Originally Posted by Donald-335i

ok guys this is gonna be a pretty noob question..

i'm going to upgrade to 2.0 very shortly and very excited to datalog. but honstly i have no idea what to look for whats good whats bad etc,

if anyone can please help me thanks in advance

There is no easy answer, it just depends what you're interested in. If you're looking for boost, boost control, air intake temperatire, fuel enrichment, etc, the JB3 2.0 interface is ideal as it will reflect the actual values.

If you are looking for knock retard to see if you're running too much boost for your octane, then the BT is a good choice. There are also hundreds of other channels you might want to log with the BT depending on what you're trying to figure out.

Mike

[Donald-335i]

Originally Posted by Mike@N54Tuning.com

There is no easy answer, it just depends what you're interested in. If you're looking for boost, boost control, air intake temperatire, fuel enrichment, etc, the JB3 2.0 interface is ideal as it will reflect the actual values.

If you are looking for knock retard to see if you're running too much boost for your octane, then the BT is a good choice. There are also hundreds of other channels you might want to log with the BT depending on what you're trying to figure out.

Mike

mike will the jb3 2.0 be able to clear codes?

[Proper Motion LLC]

Originally Posted by Donald-335i

mike will the jb3 2.0 be able to clear codes?

no

[Mike@N54Tuning.com]

Originally Posted by Donald-335i

mike will the jb3 2.0 be able to clear codes?

For full vehicle diagnostics including ECU code reading you'll want the BT cable. No other way to read/delete codes with the tune removed via the OBDII. Plus its only $120 if you buy it at the same time as your JB3. For those of you who are older customers, just share an ET cable with some friends to save a few bucks.

Mike

[scalbert]

Originally Posted by Mike@N54Tuning.com

For full vehicle diagnostics including ECU code reading you'll want the BT cable. No other way to read/delete codes with the tune removed via the OBDII. Plus its only $120 if you buy it at the same time as your JB3. For those of you who are older customers, just share an ET cable with some friends to save a few bucks.

An answer a politician would be proud of.

[StartupJunkie]

Originally Posted by scalbert

Of course it can't but it still provides some insight. It, combined with the BT interface, will provide useful information for the JB crowd.

As for sampling rate, I do hope that is improved. Of the logs posted, it appears to be in the 1 - 2 Hz range which is not very good. IMO, it would have been better to not post logs showing such a poor sampling rate.

How is logging anything at 1-2hz range useful? I mean, it's probably more misinformative than informative. Because it will filter out boost spikes, throttle pedal motions and the other 2 or 3 less than useful parameters that the jb3 can log. It would have been better just to eliminate native logging and just tell customers to log via BavTech tool (which is still limited itself by poor sampling rate).

From my experience limited experience with data acquisition and race cars, datalogging is something that needs to be done right (at least 20 samples/sec with all useful channels available) or not at all. Poor datalogging is like relying on w thermometer that sometimes reads incorrectly (or not at all) to diagnose a fever.

[scalbert]

Originally Posted by StartupJunkie

How is logging anything at 1-2hz range useful? I mean, it's probably more misinformative than informative. Because it will filter out boost spikes, throttle pedal motions and the other 2 or 3 less than useful parameters that the jb3 can log. It would have been better just to eliminate native logging and just tell customers to log via BavTech tool (which is still limited itself by poor sampling rate).

From my experience limited experience with data acquisition and race cars, datalogging is something that needs to be done right (at least 20 samples/sec with all useful channels available) or not at all. Poor datalogging is like relying on w thermometer that sometimes reads incorrectly (or not at all) to diagnose a fever.

Blah, 20 Hz is child's play. We typically log at 1kHz minimum for our tests.

But to be honest, I believe the JB logger is really just part of the interface for the loading of maps. The viewing of live data and logging is just ancillary. The JB is still fully dependant on the BT interface for logging. The only thing the JB logger provides is real boost level which of course the BT interface only shows what the JB allows it to see.

Judge for yourself on the below. It looks like the X axis are samples. But looking at the steps it doesn't look to be much better than 1 - 2 Hz.

http://www.e90post.com/forums/showthread.php?t=341687

As for the BT interface. If I limited the number of channels, I could get 15 Hz. But when logging many, 10 Hz was the norm. Not terrific but much better than the OBDII interfaces were providing; about 2 Hz.

[Mike@N54Tuning.com]

Originally Posted by StartupJunkie

How is logging anything at 1-2hz range useful? I mean, it's probably more misinformative than informative. Because it will filter out boost spikes, throttle pedal motions and the other 2 or 3 less than useful parameters that the jb3 can log. It would have been better just to eliminate native logging and just tell customers to log via BavTech tool (which is still limited itself by poor sampling rate).

From my experience limited experience with data acquisition and race cars, datalogging is something that needs to be done right (at least 20 samples/sec with all useful channels available) or not at all. Poor datalogging is like relying on w thermometer that sometimes reads incorrectly (or not at all) to diagnose a fever.

The ones I posted earlier were ~ 5 samples/second. I think ~10 samples/second would be ideal for boost, but the software is under development and that variable is currently hard-coded. ~5 samples per second of boost is extremely useful when combined with TPS and the PID targeting functions we're testing now. Some sensors like IAT are really only reliable once or twice per second.

Mike

[scalbert]

Originally Posted by Mike@N54Tuning.com

Some sensors like IAT are really only reliable once or twice per second.

That is an incorrect statement. Reliability is unchanged and is based on the sensor its self which does not change based on how fast you are doing the A/D. The usefulness is diminished as the rate at which the sensors responds to an actual change does not occur quicker than that.

Semantics I suppose.

[Proper Motion LLC]

[scalbert]

Originally Posted by Mike@N54Tuning.com

The ones I posted earlier were ~ 5 samples/second.

Honestly, it looks quite a bit slower than that. Why not use a timestamp for the X axis?

[dtp3347]

Originally Posted by scalbert

An answer a politician would be proud of.

lol

[Mike@N54Tuning.com]

Originally Posted by scalbert

Honestly, it looks quite a bit slower than that. Why not use a timestamp for the X axis?

The X scale is in 10ths of a second. So 0-50 = 5 second.

Mike

[StartupJunkie]

Originally Posted by Mike@N54Tuning.com

The ones I posted earlier were ~ 5 samples/second. I think ~10 samples/second would be ideal for boost, but the software is under development and that variable is currently hard-coded. ~5 samples per second of boost is extremely useful when combined with TPS and the PID targeting functions we're testing now. Some sensors like IAT are really only reliable once or twice per second.

Mike

Sorry Mike but when a boost control PID system operates hundreds of times per second and makes a discernible change in actual boost pressure many times per second, how is a single digit sampling rate useful for anything other than providing the user with smoothened data devoid of all the short-term abberation. (spikes, dips, oscillations, etc) that naturally occur when talking about boost control? If you can read spikes due to unacceptable sampling rate, the data isn't just useless, it's misleading and potentially dangerous.

[scalbert]

Originally Posted by Mike@N54Tuning.com

The X scale is in 10ths of a second. So 0-50 = 5 second.

I would actually state that the small ticks are 50 ms intervals. Which, with that being the case, 5 Hz is the sampling rate accoring to the charts provided.

[Mike@N54Tuning.com]

Originally Posted by StartupJunkie

Sorry Mike but when a boost control PID system operates hundreds of times per second and makes a discernible change in actual boost pressure many times per second, how is a single digit sampling rate useful for anything other than providing the user with smoothened data devoid of all the short-term abberation. (spikes, dips, oscillations, etc) that naturally occur when talking about boost control? If you can read spikes due to unacceptable sampling rate, the data isn't just useless, it's misleading and potentially dangerous.

Interestingly enough the JB3 also logs how many samples/second the PID system is analyzing. It's set to around 90/second right now. During testing I saw it go as high as 300 and as low as 50. Not a PID guy so not sure what the differences are or why its set where its at.

I can say I've been monitoring boost on my P3 gauge and its pretty much dead-nuts on with the logging software. Each channel probably has an ideal sample rate. Boost might be 10, timing might be 30, TPS might be 20, IAT might be 2, and so forth. Despite what you and Scalbert have added the new logging features have been extremely invaluable to us beta testers, and are a great addition to the JB3.

If you guys want 100 samples a second for some reason and think its useful you can always sample them yourself using external equipment.

Mike

[Mike@N54Tuning.com]

Originally Posted by scalbert

I would actually state that the small ticks are 50 ms intervals. Which, with that being the case, 5 Hz is the sampling rate accoring to the charts provided.

Here is a log I just made with the JB3 plugged in to my desktop, but not the car. Jiggled a 5v wire around on some of the I/O to make them move, and switched maps in the interface. Maybe you can tell the HRZ from that. Also interesting for those who want to see how the CSV is structured.

DataLog File

Mike