Greg, The feedback was on TMC, so I guess a roadster owner. I have invited you in on the conversation there, so you two can discuss. Regards, Mark.
On 17 Sep 2020, at 12:56 PM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
Thanks for forwarding, and Yay! Glad the facility is providing some value.
Sorry about the coding error on the example. I've not done much with coding in Javascript, and was leveraging some other random example. Newbie mistake.
To his comment about the 1.6 correction factor for speed, that's apparently a metric conversion, i.e. his car is recording miles/hr in the vehicle metrics table, and his display is (correctly) expecting an input of kilometers (even though it may be displaying in miles). Do you know what sort of vehicle he's using? Aren't all metrics standardized in metric units?
The MAF "high byte" thing is a puzzle. I checked the code, and it looks correct in terms of forwarding both bytes. But as I noted in the source, the conversion factor used in a car display is a bit of a mystery. As used with my test HUD, the display has a range of 0-19.9, and I had to apply a multiplier of 3.0 to get it to display correctly (should not be applied in his case, since he's scripted), so I would not be surprised if his display has its own quirks. I was only able to map the metric to something small for testing, hence the default mapping of MAF to v.b.12v.voltage.
Sanity check... In the MAF code, I test to be sure that the metric is not being run through a script, and only apply my 3.0 fudge factor if it is not. The test is: if(m_pidmap[mapped_pid]->GetType() != obd2pid::Script) metric = metric*3.0; I presume this is correct, and that in his case (running through a script) my fudge factor will not be applied. Yes? Otherwise, his dividing by 2.56 might simply be un-doing my multiplying by 3.0, or nearly so.
Greg
Mark Webb-Johnson wrote:
I got this feedback today from one of our users, and thought it worthwhile to share. Good to see this facility getting some use.
Regards, Mark.
P.S. I have made the documentation change he pointed out.
OVMS doc - Scripting for OBDII ECU <http://email.teslamotorsclub.com/c/eJxtTkFuxCAQe01yIwISyHLgsJf-YxgmDW1gVkC23y-9V7Is2bItR48qOPOYkwdtLAVLWsk1BtLmALevdOxgHQBZK8FIGXHaZKd2QebOteF1hwU5z6ffFVpFmwtSGWPsakdVITo80CBomC9_9v5q0_qc9MfAPzN_bsbByOVNtUFPXNrQ_M5NREbRsKZXT-VTHFwFh5iSILwXvSm9P0byLpUgztVnqN_j7A-FIL74LI3LUqj_AobJT-E>
I finally got around to playing a bit with the OBDII ECU scripting facility - it's a great tool.
I came across a minor error in the doc that had me tripped up for a while and I hope you could channel this to the right person to get it updated.
I am referring to the Google doc "OVMS v3 Advanced User Guide"
In the "Metrics scripts" section is the following example: ret1=OvmsMetricFloat("v.p.speed"); ret2=OvmsMetricFloat("v.b.power"); out=0.0; if (ret1 > 0) { out=ret2/ret1; } out; This fails since OvmsMetricFloat is undefined - it should say "OvmsMetrics.AsFloat" in the first two rows.
I managed to get my Pioneer NEX radio to show a speedometer on the home screen at last - it turns out it can only show a subset of gauges on the home screen, and the speedometer is not one of them (it offers a tach and MAF). the MAF can be tweaked to show the correct range: by setting it to metric (g/s) the range can be adjusted to 0-120. Somehow I need to multiply v.p.speed by 1.6 to get the correct mph output (which doesn't make sense to me) and then divide it by 2.56 since the OBDII ECU only sends the hibyte of the MAF response, and this is parsed as (256 * A + B)/100.
Thank you again for all the help (and the great work on OVMS!),
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev