[Ovmsdev] Hardware hacking OVMS v2 for fun and profit

[Håkon Markussen]

Hi all,

I see there is currently some HW discussion ongoing, so I'm picking up this
post again:

I want to implement the doorlock control for Think City
(vehicle_thinkcity.c) to the app.

The problem is that the module controlling the door locks (General Electric
Module from Ford, part 17ST-15K600-KB) uses K-line only.
I think the door lock switch can be triggered (K-line style) with request
22 A1 45  which returns 62 A1 45 40 for lock or 62 A1 45 80 for unlock.
I have tried to address via other ECU's which also talk k-line, but with no
success.

The GEM lock switch can be triggered by applying a gnd-pulse to the
lock/unlock switch input. The pin voltage measure about 3,5V when no gnd is
applied.

My current idea for solution is using RB4 and RB5 on the OVMS 9x2, connect
it to the GEM unlock switch and GEM lock switch.
The question is:
  1) Do I need a transceiver between the Ovms-module (RB4/RB5) and the
GEM-module (unlock/lock switch) for protection? If yes, any suggestions of
type/device?

  2)  Are there anybody with the knowledge (and time) to re-write the
utility.c/utility.h so the vehicle specific files can utilize the extra
pins (RB4/RB5 for my case)?

  3) Anybody with a better solution?

Best regards
Håkon Markussen


2013/8/24 Mark Webb-Johnson <mark at webb-johnson.net>

>
> Over the past year or so, I've had a few people ask me the same sort of
> question, so thought a single reply here would help.
>
> On the v2 module circuit board there is a unpopulated 9x2 set of holes in
> the board. You can see it on the attached picture, between the crystal and
> LEDs.
>
> You can either solder directly to this, or use a header plug/socket
> arrangement. All the unused pins from the PIC are brought out via that
> header, as well as GND, +5V and +12V. There are several free analog input
> pins, as well as digital input/output pins available for expansion. They
> are all 5V TTL level.
>
> If someone wants to use these for something, I suggest you code
> utils.h/utils.c to provide a function to initialise and control the
> required ports. Just try to make it fairly non-specific so it is of some
> use to others. Then, the vehicle module can just call the appropriate
> utils.c function, presumably in response to an SMS / net_msg command.
>
> For bi-directional sync/async comms, things are a little bit more tricky.
> The I2C pins are used by the LEDs, so you would have to sacrifice those and
> hack the code to use I2C. You could in theory do a software async, but I
> think that would be tricky. The DIAG port is just a tap between the PIC and
> the modem. Probably the best, for something sophisticated, is to use the
> CAN bus.
>
> Regards, Mark.
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20130904/4bf08974/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/tiff
Size: 272166 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20130904/4bf08974/attachment-0001.tiff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 33635 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20130904/4bf08974/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ThinkCity_GEM_doorlock.jpg
Type: image/jpeg
Size: 43302 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20130904/4bf08974/attachment-0001.jpg>