Yea!  Humming along just fine.

Question to the larger audience:  As a default, what metric should the ECU Simulator map to the Fuel Flow display element? 

Most HUDs have a default display for fuel consumption, often in Liters/hr (or configurable to that).  The scale and # of digits is limited - mine has a range of 0 to 19.9.  I was originally thinking something power-related would be appropriate, but none fit in the display's range, and doing hokey things like scaling by 1/10 fail a cursory usability test.  I'm thinking a useful display, both for use and as a verification of function, would be to display the metric v.b.12v voltage.  How does that sound?

Note that the individual elements can be re-mapped by command (config set obd2ecu.map ), and these values are stored in flash and automatically loaded when the obdii ecu is started or reloaded.  I'm just wondering what the default should be.  The other pre-loaded default PIDs are RPM, Speed, and Coolant Temperature (which is mapped to Motor temp).  One can change any of these, and/or add more as desired.

Thanks,

Greg

Try this:

OVMS > wakeup

Vehicle has been woken

it’ll jiggle, but not much else.

Would be nice to have it drive around the streets. But following roads may be a little bit tricky.

Regards, Mark.

On 9 Nov 2017, at 4:45 AM, Greg D. <gregd2350@gmail.com> wrote:

Nice, useful tool.  It also works to "drive" the ECU simulator for displaying to an external HUD / dongle.

 

But, the demo was somewhat underwhelming, as the virtual car was just sitting there.  Where is the "Gitty Up" button?

 

Greg

 

Sent from my phone, just so you know.

 

 

------ Original message------

From: Mark Webb-Johnson

Date: Wed, 11/8/2017 4:03 AM

To: OVMS Developers;

Subject:[Ovmsdev] DEMO vehicle

 

I’ve been working on a DEMO vehicle in the firmware. This is enabled by:

vehicle module DEMO

The idea is that this vehicle exercises all the metrics in a logical way. It can simulate driving, charging, and sitting idle. Along with the ‘metric set’ command, it can be used to demonstrate all the different modes. It works something like the ovms_democar at the server-side, but runs on a vehicle module itself.

It is intended to be used by firmware developers for testing their functions. Things like ovms_server_v2 and ovms_server_v3. Also, stress testing on the bench (without requiring a vehicle).

Functionality is basic at the moment, but it is working. I should be able to finish the last parts of ovms_server_v2 now.

Regards, Mark.