I'm seeing messages like this:

{"timestamp": 1360362329.484254, "valname": "transmission_gear_position", "name": "latitude", "value": "neutral"}

The USB emulator is getting a ton of invalid measurements, e.g. 10300000 for longitude, but Bluetooth is fine.

Rather than over UART, what if we sent debug messages over USB? Obviously not so useful if you're debugging USB, but handy otherwise. One cable for data and debugging.

I wrote a small test program for the LPC1769 that sets up CAN and a single CAN acceptance filter, then sent some CAN traffic at the OBD-II port. This worked fine, it printed out the data for as long as I ran it for the one message only.

I then made sure we were using the same functions in the cantranslator firmware, but when the AF goes on, we get no messages. The CAN interrupt never seems to be called. I simplified it so that only one filter is added, for the same message as the small test program, and still that doesn't work. Switching over to the AF bypass mode, it works fine (but of course we get way too much CAN traffic).

The board is alive (I can query for a version check) but there are no messages received via USB.

There are too many places where the version number needs to be changed, we are bound to forget it when making a release.

Possible just use the lower level API directly. The wrapper may not be necessary and it causes a lot of headaches for new users.

The device will not enumerate properly in Windows 7. On first attach, Windows spins for a bit and then reports "Unrecognized device". After that, nothing shows up in the Device Manager. Looking at the translator itself, it's initializing and then getting reset over and over again.

I looked into which USB event codes are being received on the device, and oddly they are 117 once and 115 multiple times - not the EVENT_CONFIGURED that we expect on other platforms. The details of this are hidden in the Microchip USB stack, so I'm a little stuck there.

Also interesting is that it seems like it's resetting the entire PIC32, not just the USB stack. The green LED goes back to flashing for 5 seconds, which is what I usually expect when it first starts up.

This needs to be fixed before you can use the CAN translator directly from Windows, e.g. with the Python library.

Borrow or share the logic from update-hex.sh

Sending from a chipKIT bench tester at 500000 over the MS pins, not receiving anything on the other end.

Cygwin needs the ncurses package to get tput.

With a CAN bus bench test rig sending vehicle data and the LPC1769 based translator flashed with the passthrough firmware, I get good raw passthrough data for 5-10 seconds, then I get about 5 translated OpenXC messages and then it freezes. On the debug log of the translator, it complains that the USB queue is full and ~5 messages are dropped, then it stops.

The translator is not hard faulted, as I can query for the version over USB's EP0 and it works fine.

The translated messages are really, really puzzling - there is no occurrence of a string like steering_wheel_angle anywhere in the code base when building for passthrough and yet it comes up with the value. I was wondering if perhaps it was still in un-erased flash memory on the chip, so I dumped the firmware back to my hard drive. Running strings on it didn't return any results for steering_wheel_angle but I'm not positive this was a complete test.

I added additional debug logging to the Python library to print out the complete message buffer received via USB and not just the successfully parsed messages. When the translated messages do appear and it freezes, we get a lot of what looks like random memory content over USB. It's a bunch of junk, with some translated messages mixed in.

My theory is that in the LPC1769 specific code, we're somehow walking off the end of an array and starting to return invalid memory addresses. Double check this, but I'm fairly certain we don't see this problem when running the CAN emulator, which indicates the problem is most likely in the passthrough-specific or CAN specific code.

Initially I was thinking that all derived signals belong not in the CAN translator, but in the host device. Now I'm rethinking that, since there could be potentially be other devices reading over USB that aren't using the Android library. It makes sense to have a two lists of signals: simple signals (the current list) and derived signals (e.g. fuel economy in mpg). It lowers the barrier for people who want to do apps with fuel economy.

Also, document how we're calculating each derived signal. Could the handlers even be part of the open soure cantranslator project, since they're just dealing with fully transforme OpenXC values?

This might be an option: http://www.libusb.org/wiki/libusb-win32

It seems more flexible and is definitely more maintained, but it's a good deal more complicated and to port our existing code was going to take more than 15 minutes, so...tabled.

This is specifically to support reading the standard OBD-II message set. The API needs to be carefully thought out, because these types of messages are significantly different than the normal CAN messages we're currently sniffing.

Is it the length or length-1?

It would be handy to have a status returned from the translator when you send a write command via USB.

With UART enabled, many more messages get sent on UART while USB has many messages dropped.

Is it waiting for hardware flow control signals?

In OS X, the code coverage output reports 97% coverage for src/tests and 0% coverage for src. I've compared the output of lcov on Linux and OS X and they are for the most part very similar. The biggest difference is that on OS X the gcov version is 4.2.1 and on Linux it's 4.7.2. Unfortunately there doesn't seem to be an easy way to get newer versions of GCC in OS X as they've deprecated it in favor of clang/LLVM.

With a little work, these changes will be useful in the main branch of the emulator.

The functions that accept cJSON objects are handy for the USB message parser, because it doesn't need to figure out exactly which type of primitive it should be, but there should be version that do accept primitives. This would be used in test cases to start, but in other places in the future - it's just good to not have types from a 3rd party library in your public API.

Figure out what's required to do it from Cygwin, and then update the bootstrap script to install the dependencies.

Is there a JSON library?

The transmit functionality should be enabled by default, but it should still have a flag to optionally disable it at compile time (primarily for pre-compiled OEM releases).

The specific error is a broken pipe, so perhaps the length we specify is greater than the actual length of data we send.

The semantics of getBitField are that it expects a 64 bit data object, so bit position 0 will correspond to the far-out-there 0th of 64 bit places. However, when you call:

uint64_t data = 0x80;
getBitField(data, 0, 1);

getBitField returns 1!

Run the test suite with valgrind to see if there's any invalid memory access. I'm seeing odd memory issues on the LPC1768, and if there's anything that we can identify running in Linux that would be much easier.