Openport Stand-Alone Logging Beta

[altaic]

Hey Colby, how would I go about logging to microsd in sniffer mode (I have already installed an obd2 tap cable)? I'm taking my car to the dealer either tomorrow or the day after, and I want to log the session.

I called yesterday and no one answered your support number throughout the day. I left a message and no one called me back.

I talked to you a long time ago when I first bought the system right when it came out, and you told me using the OP2 as a (passive, no transmit) sniffer was an interesting idea and it would be easy to do. I noticed that the driver for windows now includes a sniffer mode, and now that microsd functionality is there, I would greatly appreciate being able to use the OP2 as a standalone sniffer.

Please help me out...

Edit: Oops, you replied while I was editing.

[cboles]

It's an interesting idea, but there is no sniffer mode - it is a logger for logging parameters...

Hey Colby, how would I go about logging to microsd in sniffer mode (I have already installed an obd2 tap cable)? I'm taking my car to the dealer either tomorrow or the day after, and I want to log the session.

I called yesterday and no one answered your support number throughout the day. I left a message and no one called me back.

Please help me out...

[altaic]

It's an interesting idea, but there is no sniffer mode - it is a logger for logging parameters...

Ah I see. I noticed the windows driver includes a sniffer mode-- could this be added to stand-alone mode, perhaps "type = sniffer"?

Thanks,
Will

[dolphin]

Maybe some Evo driver could share working logcfg.txt file?

[cboles]

It's an interesting idea, but there is no sniffer mode - it is a logger for logging parameters...

Ah I see. I noticed the windows driver includes a sniffer mode-- could this be added to stand-alone mode, perhaps "type = sniffer"?

Thanks,
Will

Anything is possible... it's just a lot more complicated than that. I would have to give a full set of J2534 options, filter definitions, etc. so that you could properly sniff, and even then you might run into bandwidth issues writing to the SD card as compared to normal logging. I do lots of sniffing from the desktop, and it is like drinking from the firehose...

c

[altaic]

Anything is possible... it's just a lot more complicated than that. I would have to give a full set of J2534 options, filter definitions, etc. so that you could properly sniff, and even then you might run into bandwidth issues writing to the SD card as compared to normal logging. I do lots of sniffing from the desktop, and it is like drinking from the firehose...

c

Aside from flashing the ECU or logging tons of parameters, though, shouldn't the bandwidth be somewhat low?

For instance, the dealer will register my TPMS sensors with the TPMS module via the OBD2 port. At some point I'd also like to record a DCCD diagnostic session. I'd imagine this communication would be pretty lightweight, no need to filter.

Is there anything I could do to help out?

[cboles]

The bandwidth is low if you have a proper filter set up. The problem is that when initially doing the reverse engineering, you don't know what CAN IDs you are looking for, so it is wise to leave the filter as an all-pass, especially when you only get one chance to record something (i.e. a visit to the dealer). Try the building the canlogger demo I wrote - you will see that it picks up hundreds of messages per second from the ECU and other modules. The CAN bus is a busy place...

Anything is possible... it's just a lot more complicated than that. I would have to give a full set of J2534 options, filter definitions, etc. so that you could properly sniff, and even then you might run into bandwidth issues writing to the SD card as compared to normal logging. I do lots of sniffing from the desktop, and it is like drinking from the firehose...

c

Aside from flashing the ECU or logging tons of parameters, though, shouldn't the bandwidth be somewhat low?

For instance, the dealer will register my TPMS sensors with the TPMS module via the OBD2 port. At some point I'd also like to record a DCCD diagnostic session. I'd imagine this communication would be pretty lightweight, no need to filter.

Is there anything I could do to help out?

[altaic]

The bandwidth is low if you have a proper filter set up. The problem is that when initially doing the reverse engineering, you don't know what CAN IDs you are looking for, so it is wise to leave the filter as an all-pass, especially when you only get one chance to record something (i.e. a visit to the dealer). Try the building the canlogger demo I wrote - you will see that it picks up hundreds of messages per second from the ECU and other modules. The CAN bus is a busy place...

Ah, I see how that might be a problem, but comparing the throughputs, it doesn't seem like microsd would be a bottleneck. I have a class 10 microsd card, which corresponds to 10MB/sec read and 9MB/sec write throughput. Class 2 through class 10 cards are available, with proportionally scaled throughput. As I understand it, the OP2 serial interface is 9600 bps (1.2KB/sec), and SSM k-line is even less. I don't recall the CAN baud rate that the ECU runs, but it seems that it'd be at least a couple orders of magnitude less than the microsd. With a direct dump, i.e. no filtering, the microcontroller also would be doing less work, so that shouldn't be a bottleneck either. Am I missing something?

[cboles]

* OP2 is not serial - it just appears to the OS as such. it can support > 1Mbps full duplex data rates to/from the PC
* CAN is 500kbps typically
* OP2 SD file i/o is not asynchronous at present
* SD cards have delays of 200ms or more during some write actions due to internal block erase/rewrite housekeeping
* OP2 CAN/ISO15765 rx is interrupt based, but rx data queues are not deep enough to support lots of CAN data when a SD card that is out to lunch for 200ms

The bandwidth is low if you have a proper filter set up. The problem is that when initially doing the reverse engineering, you don't know what CAN IDs you are looking for, so it is wise to leave the filter as an all-pass, especially when you only get one chance to record something (i.e. a visit to the dealer). Try the building the canlogger demo I wrote - you will see that it picks up hundreds of messages per second from the ECU and other modules. The CAN bus is a busy place...

Ah, I see how that might be a problem, but comparing the throughputs, it doesn't seem like microsd would be a bottleneck. I have a class 10 microsd card, which corresponds to 10MB/sec read and 9MB/sec write throughput. Class 2 through class 10 cards are available, with proportionally scaled throughput. As I understand it, the OP2 serial interface is 9600 bps (1.2KB/sec), and SSM k-line is even less. I don't recall the CAN baud rate that the ECU runs, but it seems that it'd be at least a couple orders of magnitude less than the microsd. With a direct dump, i.e. no filtering, the microcontroller also would be doing less work, so that shouldn't be a bottle neck either. Am I missing something?

[altaic]

* OP2 is not serial - it just appears to the OS as such. it can support > 1Mbps full duplex data rates to/from the PC
* CAN is 500kbps typically
* OP2 SD file i/o is not asynchronous at present
* SD cards have delays of 200ms or more during some write actions due to internal block erase/rewrite housekeeping
* OP2 CAN/ISO15765 rx is interrupt based, but rx data queues are not deep enough to support lots of CAN data when a SD card that is out to lunch for 200ms

Ah, that's starting to make more sense... Damn blocking I/O. Does the USB transceiver have a queue that could be used (or looped back) while the SD write blocks? I'm just trying to figure out how to make this work. I'm hoping to not have to invest in a carpc.

[jarencibia]

Colby am I able to set a trigger with an && condition like

conditionrpn = RPM,0,>,CT,82,>,&&
action = start

where CT is coolant temp in C? I'm not sure if my RPN is correct

[altaic]

Hi Colby, It's too bad you didn't choose the LPC2368FBD100 with larger buffers and more flash. However, the LPC2364FBD100 does have 34kB of SRAM, so with all of it allocated as a CAN receive buffer, with 0.2s delay per write, it should theoretically be able to handle 170kB/sec. Even with CAN operating at the theoretical maximum of 1Mbit/sec or 128kB/sec, the receive buffer should need just ~25.6kB. I've read that typical CAN bus saturation is about half that, though, requiring a buffer of ~12.8kB.

Anyway, is the final word that the OP2 won't be able to dump to the SD card? It would be extremely convenient if it will be able to, but I've got to figure out my options now.

[cboles]

It's entirely *possible* to do, it's just a very low priority for me considering all of the other things I need to be doing, including the logging GUI features of EcuFlash. I have already written a sample CAN logger for the PC in the DLL distribution which works well - In fact I use it quite often. I think yours is a pretty execptional case where you are trying to CAN log without someone knowing. In all other cases, it is preferrable to have a laptop in front of you to be sure you are getting the data you want. Make friends with a service dept. and they will let you log while they do the work...

Hi Colby, It's too bad you didn't choose the LPC2368FBD100 with larger buffers and more flash. However, the LPC2364FBD100 does have 34kB of SRAM, so with all of it allocated as a CAN receive buffer, with 0.2s delay per write, it should theoretically be able to handle 170kB/sec. Even with CAN operating at the theoretical maximum of 1Mbit/sec or 128kB/sec, the receive buffer should need just ~25.6kB. I've read that typical CAN bus saturation is about half that, though, requiring a buffer of ~12.8kB.

Anyway, is the final word that the OP2 won't be able to dump to the SD card? It would be extremely convenient if it will be able to, but I've got to figure out my options now.

[cboles]

yes, that looks right to me...

Colby am I able to set a trigger with an && condition like

conditionrpn = RPM,0,>,CT,82,>,&&
action = start

where CT is coolant temp in C? I'm not sure if my RPN is correct

[altaic]

It's entirely *possible* to do, it's just a very low priority for me considering all of the other things I need to be doing, including the logging GUI features of EcuFlash. I have already written a sample CAN logger for the PC in the DLL distribution which works well - In fact I use it quite often. I think yours is a pretty execptional case where you are trying to CAN log without someone knowing. In all other cases, it is preferrable to have a laptop in front of you to be sure you are getting the data you want. Make friends with a service dept. and they will let you log while they do the work...

I know the service dept. pretty well, and they are cool with me, but I'd feel like I was imposing if I asked to log their session. Plus, they might be worried about damaging their SSM3/laptop/whatever by connecting it in parallel with an unknown device. I know it would be fine, but it seems like it's asking a lot.

Do you know if your CAN logger in the DLL distribution compiles on mac os x, or does it require the windows library? EDIT: After looking at it, it seems that it is dependent on the windows dll after all. At this point, I'd like to make my request for either the ability to sniff/dump to the microsd card, or mac os x support for the J2534 library.

Also, is it possible to dump both the CAN bus and K Line simultaneously? I don't know which they use for TPMS setup.

Thanks,
Will