Introduction

Although our hardware uses USB connectivity, you don’t have to be a kernel level device driver programmer or any sort of expert in the USB framework to interface our devices.Our devices simply create a virtual COM port that can be written to via all sorts of methods.

Old-school Windows programmers may be familiar with using the Windows API to play with serial ports. While this is fun, the new school .NET programmers can throw together applications in literally minutes using serialPort objects. We would love to see a C# Moates Hardware Class with all of our hardware features implemented. Unfortunately, we haven’t gotten around to doing it.

One of the downfalls of using a virtual serial port is that customers seem to have problems remembering baud rate settings. Luckily there is a (not so simple) solution. FTDI devices can be interfaced through what is known as the D2XX API. Basically, you import functions from their unmanaged DLL and you can connect to their devices without the user ever having to select a COM port. We have begun developing a C# Class based on an example from the FTDI website, but it is far from completion.

The following guide (MS Excel format) details the commands and expected responses for all of our devices.  If you don’t see something you need or have questions, email us.

Download the Moates Hardware Interfacing Guide here (v19 2/11/10)

In terms of understanding what commands are used when and how they fit together – looking at an ADX for TunerPro RT that makes use of the device is a great way to put things together.  The ADX has sections for connect, initialization, packets, etc.

Devices with Onboard Logging

Although the command structure is outlined in the above document, the procedure for using the onboard logging facilities of newer integrated devices is complex and the order of operations maters.  The example that will be illustrated here will be for the Demon / Demon2 but it should be more or less the same for the NEMU and have much in common with the SuperLogger.

1. Pause for data rate (otherwise TunerPro could potentially hammer the Demon faster than it could retrieve new packets from the ECU) and limit to 10Hz (or whatever you want)
2. DR command: setup packet = “0x44 0x52 0x0F 0x17 0x00 0x05 0x04 0x05 0x05 0x1D 0x1B 0x14 0x1E 0x15 0x05 0x05 0x20 0x10 0x11 0x12 0x13 0x05 0x05 0x16 0x22 0x1C 0x17 0x18 0x05 0x05 0x19 0x1A 0x21 0x22 0x1F” =
   1. 0x44(‘D’) 0x52(‘R’)
   2. 0x0F(ADC fetch mask = all channels)
   3. 0x17(baud rate divisor 17hex=23decimal for 38400 baud)
   4. 0x00(c=reserved)
   5. 0x05(d=reserved)
   6. 0x04(4 elements in structure, can use ‘0’ for ADC only)
   7. 0x05(5 bytes to send for first element)
   8. 0x05(five response bytes expected)
   9. 0x1D 0x1B 0x14 0x1E 0x15 (req1)
   10. 0x05 0x05 0x20 0x10 0x11 (req2)
   11. 0x12 0x13 0x05 0x05 0x16 (req3)
   12. 0x22 0x1C 0x17 0x18 0x05 (req4)
   13. 0x05 0x19 0x1A 0x21 0x22 (req5)
   14. 0x1F (checksum)
   15. expect “Okay” repsonse: 0x4f (‘O’)
3. Send retrieve packet: 0x64 (‘d)
4. Wait for packet of configured length (in this case: 30 bytes)

(above section is work in progress)