NEW: OpenFlash Tablet G-Meter and Performance Driving Pack

[Vmax911]

So if we can now monitor tire pressure, and chance we can disable the darn "low pressure" light all together?

[Shiv@Openflash]

Originally Posted by Vmax911

So if we can now monitor tire pressure, and chance we can disable the darn "low pressure" light all together?

Pressure cannot be monitored yet. Just individual tire air temp. Can't make promises to eliminate safety warnings due to liability concerns.

[Shiv@Openflash]

Originally Posted by churchx

How about individual higher sampling rates per each monitored setting where it's needed, and slower ones (or dropping redundant subintervals data) where it's not?
Or .. in future OFT models wifi NAS mount or usb external storage for saving big loads of detailed full logs at less space-limited elsewhere?

There is a lot of things that can be done with regards to the datalogging code. But it's a tradeoff between time constraints more than anything else. We have an ever-growing To Do list which means that we need to prioritize updates carefully. As for storage capacity, there is plenty of it on the OFT. It is in the viewing/plotting domain where huge files become more a problem due to wait times.

[Jrdad]

Originally Posted by Shiv@Openflash

Pressure cannot be monitored yet. Just individual tire air temp. Can't make promises to eliminate safety warnings due to liability concerns.

Could the psi be adjusted for when the light turns on or is that a mechanical problem? I like to run my tires at 30psi but on a cooler day it's enough to set the light off.

[Shiv@Openflash]

Originally Posted by bee_are_zee

@Shiv@Openflash

Just a thought; how difficult would it be to make logging rate user selectable for times when you are logging engine parameters for tuning vs logging an autocross run?

That will take some time. I don't see it happening in the foreseeable future.

[Aztec]

Fantastic update Shiv!! Now I just need more info on that OFT350
And if I already have the OFT/OFH, is there a greater discount?

[CSG Mike]

Originally Posted by Shiv@Openflash

Increasing the logging rate is easy. But it's a trade off between logging rate and datalog file size. People tend to get caught up with logging rates when there is little or no benifit of logging engine channels once you go beyond a certain rate. It's not like we are datalogging formula one cars here. But to be fair, once you start logging things like G sensors, faster rates may be useful. And if that turns out to be the case, we will adjust the logging rate accordingly.

10hz is not really useable for track duty; 100hz is.

I don't mind having datalogs in the hundreds of megabytes.

[Shiv@Openflash]

Originally Posted by CSG Mike

10hz is not really useable for track duty; 100hz is.

I don't mind having datalogs in the hundreds of megabytes.

Please explain how 10hz is not useable but 100hz is.

[Thorpedo]

Originally Posted by CSG Mike

10hz is not really useable for track duty; 100hz is.

I don't mind having datalogs in the hundreds of megabytes.

Yeah bro, anything less than 100hz and your coolant temp log just isn't accurate enough.

So, what you're saying is... a 10hz Gforce reading is useless for track duty? Uhh.... Really? Now of course there are certain parameters where 100hz would be really useful (wheel speed), but saying 10hz "is not really useable" generally is, well... silly.

[CSG Mike]

Originally Posted by Shiv@Openflash

Please explain how 10hz is not useable but 100hz is.

My driving corrections happen in less than 0.2s. Seeing one "spike" of steering angle, with momentary wheelspin that only occurs for 0.35s doesn't help me figure out what's going on, when the data comes at a rate of 0.1s.

with 100hz vs 10hz, you're comparing maybe 5 data points during the incident, vs 50.

[CSG Mike]

Originally Posted by Thorpedo

Yeah bro, anything less than 100hz and your coolant temp log just isn't accurate enough.

So, what you're saying is... a 10hz Gforce reading is useless for track duty? Uhh.... Really? Now of course there are certain parameters where 100hz would be really useful (wheel speed), but saying 10hz "is not really useable" generally is, well... silly.

Yes, I am.

How long do you think the impulse of hitting a berm, or a dip lasts for?

I'm not saying that all channels need to be polled at 100hz. I poll voltage at 1hz unless I'm doing diagnostics. I'd just like the option to be able to bump the poll rate up.

[steve99]

Originally Posted by CSG Mike

My driving corrections happen in less than 0.2s. Seeing one "spike" of steering angle, with momentary wheelspin that only occurs for 0.35s doesn't help me figure out what's going on, when the data comes at a rate of 0.1s.

with 100hz vs 10hz, you're comparing maybe 5 data points during the incident, vs 50.

True however its also going to depend on traffic on the CAN buss and if the BCM/VSC updates at 100hz .

No use interrogating the BCM/VSC for data at 100hz if the BCM only updates at 20hz. or the CAN buss wont respond to that level of interrogation.

[efactor84]

Is there going to be more CAL files to be unlocked in the near future?

[churchx]

Originally Posted by Shiv@Openflash

There is a lot of things that can be done with regards to the datalogging code. But it's a tradeoff between time constraints more than anything else. We have an ever-growing To Do list which means that we need to prioritize updates carefully. As for storage capacity, there is plenty of it on the OFT. It is in the viewing/plotting domain where huge files become more a problem due to wait times.

If main issue is OFT speed to work with/display data, not storage space, then another easy way would be split big log file in smaller. Be it in eg. 5 or 1 min increments, or by user configurable time count. So then feature to be added: "auto-splitting/rotating" logfile output with adding timestamp (of log end/cut) to filename + UI for selection which logfile to display.