
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards, Mark.</div><div><br></div><div><br></div><div><img id="e8b6dc87-0cc2-48b3-9384-a4231bf592d3" height="210" width="320" apple-width="yes" apple-height="yes" src="cid:F9CC065C-B918-4447-AB3D-806A6DCCDA5A"><img id="60b783c5-9c80-41e1-aeec-aea050ef3730" height="240" width="320" apple-width="yes" apple-height="yes" src="cid:6E022E85-30CA-4B44-9BAF-E05BB10CE8EA"></div></body></html>