|Anonymous | Login | Signup for a new account||2019-10-14 10:34 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000442||Firmware||Serial Comms||public||2011-11-28 11:46||2011-11-28 21:14|
|Target Version||0.3.0||Fixed in Version|
|Summary||0000442: Design New Datalog API|
|Description||The existing API is not good enough. Additionally Dave is strongly against a generic memory based streaming control setup and would prefer a single call like the current deprecated one. The request datalog API call should probably be more generic too, such as request without body = whatever is in config, request with body = 8 bit ID = that type of datalog. The semantics could be to have the datalog stream type in flash only config, and copied to a dedicated variable at init time. That variable could then be updated using a set stream type call. The boot time default would be configured like any other normal setting. Other possibilities exist too.|
|Tags||No tags attached.|
|Risk of Breakage||medium|
|Please comment on this proposal.|
At first glance, I'd guess that a datalog call that specifies a well defined 8 bit code to define certain actions, examples:
i.e. CORE codes
0: disable any/all active datalog streams, return error if no streams are running.
1: enable stock datalog highspeed streaming of all values (same as now)
2: one-shot datalog burst (all values, one shot only, similar to current polling)
3-255: i.e. custom logs, however mtx doesn't and is unlikely to ever support these, as the UI allows filtering out what variables we want into a log file from the datalog blob. The ONLY advantage of a selectable vars in the stream is a slight increase in speed, but honestly, is this REALLY REQUIRED, especially considering all the special logic, parsing and other crap that is needed on the tuning software side for something that may if ever be used by 1-3 people.
LA logs should not be in part of this at all as they are non-packetized data AFAIK and are only for extreme development techniques using cutecom or similar. Correct me if I am wrong.
I have yet to see any real and true value of configuring 'N' datalogs in firmware. Sure the concept and flexibility sounds nice, but who out of the "typical" end user would honestly ever need to use it or want it when the tuner gives the ability to filter out whichever variables the user is interested in. the only potential value I can see is speed, thoguh the logs are already fairly quick for our needs, but it would be for an extremely small niche set of users, if any at all... We're not building a serial oscilloscope here....
Thanks for the feedback! Very thorough :-)
Re LA, it's awesome for on-car diagnostics during cranking/idle and for setup config verification. It's been great in the field already, but only for low res wheels. I'll implement something better in future, and save this for streaming any general byte in the firmware at 1khz (10x + the std log rate). The extra sampling comes in very handy for spotting issues, I assure you. I'm not building in these features for dev toys, they're for install and fault diagnostics, and invaluable at that.
Also, LA is packetised, it's just a byte, wrapped in a minimal packet.
I currently have about 10 or so modes in mind. Each has a distinct and important use. Time will tell which ideas are winners and which are not. I see some of them getting a lot of use, and others getting very little.
|Copyright © 2000 - 2011 MantisBT Group|