Author Topic: Continuous data capture using STN1110  (Read 6061 times)

axscan

  • Newbie
  • *
  • Posts: 11
Continuous data capture using STN1110
« on: December 11, 2011, 04:18:59 pm »
Hi,

With help from this forum and Vitality I was able to read some CAN-bus data from the OBD port of Toyota RAV4 2006 using STN1110. However I have 2 big concerns with the data I have captured. I have copied the data and the end of this post.

1. Data Error
2. Buffer Full

1. Data Error
We have a few STN1110s mounted on Sparkfun boards. On few of them we have added extra cap for better noise immunity. Still we see Data Error when we read CAN-bus data from the OBD port. The error is see on various cars and not specific to one car. The pin connections are new and make full contact, but still there are Data Errors. Why does this happen? and how can this be corrected?
From my understanding, any of the CAN protocols are robust and less prone to any data errors, also the bus itself is not fully utilized interms of bandwidth, so where and to what are these Data Errors attributed to?

2. Buffer Full
These were the set of AT commands I typed in OBDWiz and MTTY and on both, I see the same Buffer Full message after which there is no more data.
AT Z
AT DP
AT H1
AT MA
I even tried to set AT AR and then do an AT MA, still the buffer gets full. The only way I was able to read more data is by repeating AT MA after every Buffer Full. Is there any better way to read CAN-bus data continuously from the OBD port using STN1110?

Eagerly looking forward for any responses.

Thanks and regards
axs

Data from a single read
========================
>
624 1A 00 41 49 49 40 00 00
0B0 00 00 00 00 11 07
0BA 15 F7 C9
0B2 00 00 00 00 11 07
224 20 00 00 00 02 FC 00 28
2C1 08 FF 4F FF 8E BA 00 68 <DATA ERROR
2C6 00 00 00 10 00 00 00 E0
2D0 06 66 09 00 10 00 00 5F
020 20 00 07
0B4 00 00 00 00 74 00 00 30
630 17 00 00 00 00 00 00 00
2C4 03 3C 00 1B 00 80 21 C9
2D5 2E 1D
260 0E 00 00 00 00 00 00 78 <DATA ERROR
0B0 00 00 00 00 11 08
235 00 00 00 3B
0B2 00 00 00 00 11 08
638 13 00 18 00 00 00 00 00
3A1 00 00 00 00 00 00 00 00
020 20 00 07
223 07 28 00 00 00 10 00 6C
0B4 00 00 00 00 74 00 00 30
0B0 00 00 00 00 11 09
0BA 15 F7 C9
0B2 00 00 00 00 11 09
224 20 00 00 00 02 FA 00 28
260 0E 00 00 00 00 00 00 78 <DATA ERROR
020 20 00 07
0B4 00 00 00 00 74 00 00 30
2C4 03 3A 00 1B 00 80 21 C7
BUFFER FULL

Vitaliy

  • ScanTool.net Staff
  • Veteran
  • *
  • Posts: 2263
  • Forum Cop
    • OBDScantool.com
Re: Continuous data capture using STN1110
« Reply #1 on: December 11, 2011, 05:33:30 pm »
You're not setting the protocol explicitly, therefore STN1110 defaults to ISO 15765. Some of the data on your CAN bus is "raw" CAN (ISO 11898), in which case you get the <DATA ERRORs. You need to set the protocol manually to Protocol B, and configure it for 11-bit/500kbps.

By default, STN1110's UART baud rate is set to 9600. CAN runs at 500000 bps, more than 50 times faster, hence the "BUFFER OVERFLOW". Change the UART baud rate to a higher value, and if you still get the error, use message filters to eliminate unwanted traffic.

Vitaliy
Need to decode a diagnostic trouble code? Try DTCSearch.com

axscan

  • Newbie
  • *
  • Posts: 11
Re: Continuous data capture using STN1110
« Reply #2 on: December 12, 2011, 05:18:50 am »
Thanks for the quick reply Vitality.
I haven't checked anything after your reply, but previously I had set the UART baud rate to 500Mbps and still I had the Buffer overflow. Unfortunately I cannot use a message filter as I try to use as many messages/ signals on the CAN bus as I can/know. I try to use pattern recognition to identify new messages, so all the messages are important.

I guess by protocol B you mean ISO 11898. I will try this. While using OBDWiz I use AutoDetect and connect, and I assumed that it would fix to the detected protocol.

I will check and update.

Thanks once again.
axs

Vitaliy

  • ScanTool.net Staff
  • Veteran
  • *
  • Posts: 2263
  • Forum Cop
    • OBDScantool.com
Re: Continuous data capture using STN1110
« Reply #3 on: December 12, 2011, 04:30:44 pm »
Thanks for the quick reply Vitality.
I haven't checked anything after your reply, but previously I had set the UART baud rate to 500Mbps and still I had the Buffer overflow.

You mean 500kbps? ;) Try 2Mbps. Also, go to Control Panel->System->Device Manager->Ports, find your port, Properties->Port Settings->Advanced, and set "Latency Timer" value to 1.

Quote
Unfortunately I cannot use a message filter as I try to use as many messages/ signals on the CAN bus as I can/know. I try to use pattern recognition to identify new messages, so all the messages are important.

Filters are most useful when you're looking for data patterns. If you are looking for new CAN IDs, set pass filters to "pass all", and selectively block individual CAN IDs. For example, if you're looking for a door unlock message, you can block all engine and transmission CAN IDs.

Quote
I guess by protocol B you mean ISO 11898. I will try this. While using OBDWiz I use AutoDetect and connect, and I assumed that it would fix to the detected protocol.

Well, yes -- OBDwiz correctly detects ISO 15765. The problem is, on your CAN bus, you have a mix of ISO 15765 and ISO 11898 messages. You must therefore set the protocol to the lowest common denominator, ISO 11898.

Good luck,

Vitaliy
Need to decode a diagnostic trouble code? Try DTCSearch.com

axscan

  • Newbie
  • *
  • Posts: 11
Re: Continuous data capture using STN1110
« Reply #4 on: December 13, 2011, 06:36:58 pm »
Hi Vitality,

I tried out all options as you mentioned. Now I am back to 2 cars and 2 problems !! (I test most of what you suggest on 2 cars to make sure everything is set properly)

1. Data Error issue
I selected protocol B as you mentioned with
AT PB 2C 01
AT SP B
AT MA

On Toyota RAV4, the data errors stopped appearing as you mentioned. I noticed that the protocol it was detecting on RAV 4 was ISO 15765-4 and by switching to ISO 11898 I was able to see all the messages without the data error.

On VW Jetta 2003, I noticed that protocol ISO 9141-2 was detected using OBDWiz and there were 2 ECUs detected ECU 10 and ECU 1A. OBDWiz forces me to select one of the ECUs and I had selected ECU 10. I was still seeing data error frames on this too. After I switched to Protocol B, OBDWiz would not read any data on Jetta and I had to reset the connect for it to detect ISO 9141-2 and then it would start reading data along with error frames.
I also use MTTY (hyper terminal like software) and on this, Toyota RAV4 reads CAN-bus data without error frames using protocol B. However on Jetta, there is no information read when I select protocol B and when I hit AT MA, it goes into a forever searching ... mode.

From your suggestions, I understood that there was a common denominator (i.e, ISO 11898 for RAV4, but what would it be for Jetta?) If this is the case, then will every different car have such different denominators? How to go past this issue for all cars in general?

2. Buffer Full
Sorry, I meant 500 kbps  :P. I did change the Latency Timer value to 1. However this did not help. The best part is that on both the cars, Toyota RAV4 and VW Jetta, the protocol is detected at 9600. I had previously set baud rate or kbps to a high value in Device Manager, and after your suggestion, I checked all settings for all the values listed in the dropdown menu. After setting every time in Device manager, I checked it for all the values listed in OBDWiz and MTTY (same standard values) and was able to only see data when the bit rate was 9600 in both OBDWiz and MTTY. In OBDWiz, I tried both auto and manual settings, and in Auto detect mode, it would only detect the protocol for and at 9600 no other time. Also when both OBDWiz and MTTY detected the protocol at 9600, there would be a Buffer Full like I had mentioned earlier (original problem).

As a check, I wrote a small code to enter AT MA (or ST MA) after every buffer full and drove around collecting some data and noticed that there was loss in the data. I am loosing a lot of data between the Buffer Full and the next AT MA. I even tried eliminating the headers and spaces but it does not help the cause and it becomes impossible for me to understand which frame is for which message ID. The only option I am left with is to put filters as you mentioned but that defeats the purpose as I am in an exploratory phase, where I drive and collect data, then look at how the data patterns change and then guess which message ID has what data.

I guess I will be doing something wrong in some setting or I am missing some command through which I can read all the CAN bus data without loosing it due to Buffer Full. Please guide me in fixing these concerns.

Thanks a lot once again,
axs

Vitaliy

  • ScanTool.net Staff
  • Veteran
  • *
  • Posts: 2263
  • Forum Cop
    • OBDScantool.com
Re: Continuous data capture using STN1110
« Reply #5 on: December 14, 2011, 03:34:08 pm »
2003 VW Jetta uses one of the ISO protocols (not CAN). Please post your comm log from OBDwiz, so I can see the <DATA ERRORs.

You're getting BUFFER FULL messages, because your UART baud rate is set to 9600. You need to change the baud rate, and save it to non-volatile memory. Like this:

STSBR 115200
STWBR

Vitaliy
Need to decode a diagnostic trouble code? Try DTCSearch.com

axscan

  • Newbie
  • *
  • Posts: 11
Re: Continuous data capture using STN1110
« Reply #6 on: December 15, 2011, 12:21:34 pm »
Hi Vitaliy,

To reduce too many variables, I will currently work on Toyota RAV 4 and wont be working on Jetta till the next week. So Vitaliy, I will check and post Jetta related issue late on.

Back to Toyota RAV 4. This is what I have done so far -
I have fixed it to the common denominator ISO 11898 as you mentioned, following these steps.
AT PP 2C SV C0
AT PP 2C ON
AT PP 2D SV 01
AT PP 2D ON
AT Z
AT SP B
AT H1
AT MA

With this, I was able to get rid of the Data Error and read the CAN bus data.

For the Buffer Full, I did the following as you suggested.
STSBR 115200
STWBR

Still the Buffer Full issue remains. Attached are some of the related snapshots. Using MTTY (hyper terminal like sw), I noticed that AT Z and other commands started working when I set to 115200 during connection. Also I could see data when I do AT MA, but still it would show a Buffer Full.

Snapshot 1.jpg: I did an Auto Detect and the device was detected on COM4 with the new baud rate of 115200
Snapshot 2.jpg: As can be seen, in the USB COM port properties, I have set it to 115200 bps and latency time is also set to 1 msec as you suggested.
Snapshot 3.jpg: MTTY is another sw I use to see data from and as can be seen in the snapshot, there is BUFFER FULL, and just to show that the connection is established, I again did an AT Z and AT SP B. Also from top, you can see that I am connecting to COM4 at 115200.
Snapshot 4.jpg: After changing the baud rate, I just wanted to check if ISO 15765 would work and this is the error message I got.

>AT Z
ELM327 v1.3a
>AT SP B
OK
>AT H1
OK
>AT MA
260 0E 00 00 00 00 00 00 78
020 60 00 07
0B4 00 00 00 00 C8 00 00 84
025 00 01 30 00 78 78 78 C6
022 01 F3 01 F3 00 20 00 32
023 01 F7 02 0A 00 00 2E
2C1 08 FF 5A FF 7E BA 00 63
2C6 00 00 00 10 00 00 00 E0
2D0 06 7C 09 00 10 00 00 75
0B0 00 00 00 00 11 08
235 00 00 00 3B
0B2 00 00 00 00 11 08
3A0 00 00 00 00 00 00 00 2E
020 60 00 07
223 00 20 00 00 00 00 00 4D
0B4 00 00 00 00 C8 00 00 84
025 00 01 30 00 78 78 78 C6
022 01 F3 01 F3 00 20 00 32
023 01 F5 02 0E 00 00 30
2C4 03 4E 00 20 00 80 21 E0
0B0 00 00 00 00 11 09
0BA 01 F3 B1
0B2 00 00 00 00 11 09
224 00 00 00 00 00 00 00 08
2D5 2E 1D
260 0E 00 00 00 00 00 00 78
020 60 00 07
0B4 00 00 00 00 C8 00 00 84
025 00 01 30 00 78 78 78 C6
022 01 F3 01 F3 00 20 00 32
023 01 F8 02 0E 00 00 33
621 11 00 00 00 00 00 00 00
0B0 00 00 00 00 11 0A
235 00 00 00 3B
0B2 00 00 00 00 11 0A
320 00 00 26
2C1 08 FF 5A FF 7F BA 00 64
2C6 00 00 00 10 00 00 00 E0
2D0 06 7B 09 00 10 00 00 74
020 60 00 07
223 00 20 00 00 00 00 00 4D
0B4 00 00 00 00 C8 00 00 84
025 00 01 30 00 78 78 78 C6
022 01 F3 01 F3 00 20 00 32
023 01 F9 02 0B 00 00 31
624 1A 00 41 49 49 40 00 00
260 0E 00 00 00 00 00 00 78
2C4 03 50 00 20 00 80 21 E2
2D5 2E 1D
0B0 00 00 00 00 11 0B
0BA 01 F1 AF
0B2 00 00 00 00 11 0B
224 00 00 00 00 00 00 00 08
020 60 00 07
0B4 00 00 00 00 C8 00 00 84
025 00 01 30 00 78 78 78 C6
630 17 00 00 00 00 00 00 00
022 01 F3 01 F3 00 20 00 32
023 01 F7 02 0A 00 00 2E
0B0 00 00 00 00 11 0C
235 00 00 00 3B
0B2 00 00 00 00 11 0C
442 40 02 00 00 00 00 00 00
638 13 00 18 00 00 00 00 00
260 0E 00 00 00 00 00 00 78
020 60 00 07
223 00 20 00 00 00 00 00 4D
0B4 00 00 00 00 C8 00 00 84
025 00 01 30 00 78 78 78 C6
022 01 F2 01 F3 00 20 00 31
023 01 F6 02 0E 00 00 31
2C4 03 48 00 20 00 80 21 DA
2C1 08 FF 5C FF 80 BA 00 67
2D5 2E 1D
BUFFER FULL

This is what I get after correcting the Data Error and after setting the UART baud rate to 115200. I even tried for both higher and lower baud rates but it doesn't even accept higher than 115200 and buffer full for lower values. I also tried AT BRD command upto 400 kbps and still the same - doesn't work for higher and buffer full for lower.

Please let me know if I am doing anything wrong in my settings or if I should change anything to make the data records continuously without a Buffer Full. As I mentioned I also tried removing headers, extra spaces but that doesn't help. After every buffer full, if I hit an ENTER, it writes the next chunk of data, but I loose a lot of data inbetween.

Thanks and regards,
axs
« Last Edit: December 15, 2011, 12:24:33 pm by axscan »

Vitaliy

  • ScanTool.net Staff
  • Veteran
  • *
  • Posts: 2263
  • Forum Cop
    • OBDScantool.com
Re: Continuous data capture using STN1110
« Reply #7 on: December 16, 2011, 05:25:35 am »
axscan,

There is no magic bullet. You have a busy 500 kbps bus, so you need to either figure out how to increase the UART baud rate, or use filters. If you can't get the Sparkfun board to communicate faster than 500 kbps, get an OBDLink or OBDLink SX.

Your logs show that a faster baud rate lets you capture more messages (74 vs 30) before the buffer overflows. Block a few frequently occurring CAN IDs (022 and 023 look like good candidates), and you will eliminate the BUFFER OVERFLOW error.

Vitaliy
Need to decode a diagnostic trouble code? Try DTCSearch.com

axscan

  • Newbie
  • *
  • Posts: 11
Re: Continuous data capture using STN1110
« Reply #8 on: December 16, 2011, 10:38:50 am »
Thanks for the reply Vitaliy, I really want to look for that magic bullet :P
I will try other options and also see if I can reduce info by using filters.
I will keep you posted as I proceed.

Thanks and regards,
axs