[Ovmsdev] i-Miev/C-Zero/iOn

[Tom Saxton]

Do you have the physical switch on the board in the right location? That
messed me up when I set up the new V2 device for our car. Slide it to the
position nearest the white connector (v1) or away from the edge of the
board (v2).

    Tom

On 9/15/13 2:02 PM, "Thomas Bergo" <thomas.bergo at gmail.com> wrote:

>Finally got some time to work on the i-Miev implementation.
>But I'm facing some issues setting up the car module.
>- SMS is working and are able to send messages to the car module and get
>answers.
>- Problem getting the GPRS to work. Get "Not connected" and "Not
>connected (0x0041) when sending GPRS?
>- No connection from the iOS app to server. Only red flashing antenna.
>
>Any advise?
>
>
>Still has some debugging to do on the i-Miev code, as i'm only get "SOC:
>0%" from STAT?
>
>Regards, Thomas
>
>
>
>
>2013/5/1 Mark Webb-Johnson <mark at webb-johnson.net>
>
>
>I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If
>you pull head you'll get it. This is just a stub. You'll need to setup
>the CAN IDs you want to receive (in the filters), and then add the
>decoding logic to update the car_* variables.
>
>Regards, Mark.
>
>Regards, Mark.
>
>On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo at gmail.com> wrote:
>
>
>
>
>Hi,
>So far the following CAN messages is discovered by Priusfan published on
>myimiev forum:
>
>SOC
>RPM
>Range
>Battery current
>Battery voltage
>Speed
>Odo
>Battery cell voltage
>Battery cell temperature
>
>So we still have to find Car On/Off and the charging status.
>
>Those messages are available as Mitsubishi has made a CAN Gateway where
>those data is provided.
>http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf
>
>
>Regarding the two-character abbreviation I think Brand-Model (MI) as TR
>and RT is most intuitive. So my vote goes to MI.
>
>I'm interested in using the OVMS v1 HW for logging of CAN messages. How
>to pay for postage?
>
>Regards, Thomas
>
>
>mandag 29. april 2013 skrev Mark Webb-Johnson  følgende:
>
>
>Thomas,
>Earlier this year, Matt Beard mentioned he was interested in doing i-Miev
>support, but I'm not sure of his status. He is on this list, so should
>see this. There are also several OVMS users who have that car in their
>stable, so the requirement is definitely there.
>
>It is probably worth firstly doing a quick feasibility check, to see what
>level of OVMS support is possible:
>
>
>Firstly, What are the specs for the CAN bus? What baud rate is it, and
>what is the connector? There are  just three messages that are key to
>feasibility:
>
>
>
>
>     1. SOC - battery state of charge - car_SOC
>     2. Car On/Off (ignition switch, or Park/Drive gear lever) -
>car_doors1 [bit7]
>     3. Car Charging (true or false) - car_doors1 [bit 4]
>
>
>
>
>
>If those three are available, and readable by the OVMS hardware, then the
>project is most likely feasible. There are lots of other parameters
>(range, temperature, odometer, speed, vin, tpms, etc) that are nice to
>have, but are either optional (nice-to-have) or can generally be derived
>from these three key messages - so long as they can be found. For
>example, on the Volt/Ampera we don't know the detailed charge messages,
>but do know whether the car is charging or not - we can assume charge
>interrupted if the charge finishes before 95% complete. Similarly, if the
>range of the car is XXkm, we can estimate the current range based on XX *
>SOC%. If the car has no GPS details on the CAN bus, then we can use the
>GPS in the OVMS module itself.
>
>
>
>
>What vehicle two-character abbreviation do you think is suitable: IM or
>MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla
>Roadster).
>
>If you can let me have the can bus specs and information on the above 3
>messages, I will create you a stub vehicle implementation.
>
>Regards, Mark.
>
>P.S. With reference to the development guide
>(https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/
>OVMS_Development.pdf), these are the current set of parameters that OVMS
>supports.
>
>
>Vehicle Module Development Checklists Development Checklists
>
>You can use these checklists to know what vehicle parameters the OVMS
>system supports, and how you can map a specific vehicle to these.
>Parameter
>Purpose
>Vehicle Support Notes
> 
>Vehicle Identification
>car_type
>Vehicle type identified
> 
>
>car_vin
>Vehicle VIN
> 
>
> 
>Parameter
>Purpose
>Vehicle Support Notes
> 
>GPS Status
>Vehicle GPS
>Does the vehicle have a built-in GPS? If so, complete the following.
> 
>
>car_gpslock
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>OvmsDev mailing list
>OvmsDev at lists.teslaclub.hk
>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
>
>
>
>
>
>
>_______________________________________________
>OvmsDev mailing list
>OvmsDev at lists.teslaclub.hk
>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
>
>
>
>_______________________________________________
>OvmsDev mailing list
>OvmsDev at lists.teslaclub.hk
>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev