Hitachi ZW220-7

Ask for and share advice on using the PicoScope kit to fix Heavy Duty and Off Highway machinery here
Post Reply
Bruno.Carreira
Newbie
Posts: 3
Joined: Thu Feb 08, 2024 11:26 am

Hitachi ZW220-7

Post by Bruno.Carreira »

Dear all,
I'm trying to decode a CAN Bus signal on Hitachi ZW220-7 Wheelloader to try diagnose a different machine with a intermittent abnormal update rate on the inlet NOX sensor. I tried J1939 protocol with 250kbit and 500kbit baudrate but without success. Can someone give me some guidance?
Channel A - CAN H
Channel B - CAN L
Chanel C - Current clamp power supply NOX, temp and adblue sensor
Chanel D - Voltage power supply NOX, temp and adblue sensor
Engine Cummins B6.7(EU Stage Ⅴ)
Attachments
Hitachi_2023_20240212-0002.psdata
(19.5 MiB) Downloaded 33 times

Martyn
Pico Staff Member
Pico Staff Member
Posts: 360
Joined: Thu Aug 11, 2011 7:43 am
Location: Cambridgeshire

Re: Hitachi ZW220-7

Post by Martyn »

As you have used A-B you need to use the Invert option in the decoder setup, alternatively create the maths channel as CanHigh - CanLow which would be B-A
You will need to change the Baud Rate to 250kbaud as shown here
Decoder Settings.png
Martyn
Technical Support Manager

ben.martins
Pico Staff Member
Pico Staff Member
Posts: 543
Joined: Tue May 16, 2017 1:02 pm

Re: Hitachi ZW220-7

Post by ben.martins »

Hi Bruno,

Thanks for uploading this capture and hopefully Martin was able to help you to decode your CAN data.

Going a bit further on this and you may already have this information. The transmission rate for the NOx sensors is 50ms. The easiest way to determine the refresh rate is to look for the source address relating to one or both of the NOx sensors, in this case 0x51 and 0x52 for NOx sensor 1 and 2 respectively. When we observe your data we can see that on buffer 1, 0x51 appears at 17.28ms and then appears on buffer 2 at 27.86. Given we have a time base of 5ms/div and 10 divisions on the waveform grid, this equates to 50ms of total time but somehow we have gained 10ms between the two messages.
J1939 NOx sensor transmission rate.png
This can be attributed to the fact there is a trigger on channel C, which may have meant the software waited momentarily before starting the capture and we also have the time that the software takes to send the block of data over to the PC. Going forward it might be worth increasing your timebase to something longer like 200ms/div. This not only gives you streaming data, but more than enough time to see the transmission rate of the NOx sensors. Alternatively you can load the J1939 serial decode guided test which will set the scope for you along with the decoder and the maths. You can see more on this test on our YouTube channel here - https://youtu.be/AJT1hXxhW54?si=gdZuT08WYNCUeN33&t=903.

I hope this helps and please let us know how you get on.

Kind regards

Ben

Bruno.Carreira
Newbie
Posts: 3
Joined: Thu Feb 08, 2024 11:26 am

Re: Hitachi ZW220-7

Post by Bruno.Carreira »

Thank you for your support. I was able to decode the messages and apply the link file to recogize the addresses. Now what I want to do is to connect the Pico to the faulty machine and drive it until the fault code appears and get it record in Pico. How can i set a trigger on a faulty NOX outlet sensor CAN message ?
Attachments
Captura de ecrã 2024-02-16 122154.png

ben.martins
Pico Staff Member
Pico Staff Member
Posts: 543
Joined: Tue May 16, 2017 1:02 pm

Re: Hitachi ZW220-7

Post by ben.martins »

Hi Bruno,

Unfortunately, it is not possible to trigger on decoded messages. This is down to the way we currently decode which happens only once the buffer is full or if the capture is stopped.

I would suggest an option would be to remove the decoder and just have channels A and B for CAN H and CAN L free running. If you're using the guided test this will get you at least 4 buffers, if not more, of CAN data. Once the software hits the buffer limit you will see the number of waveforms no longer increasing. This is where the first buffer is now overwritten and we start a sort of circular buffer. This means that when you notice the fault, warnings on the dash etc, you will need to stop the scope and most importantly save the data. You can then create the decoder and then start looking back through the CAN data.

The alternative is to 'create' a trigger using a simple circuit to create a pulse which you can then measure with the scope on one of the free channels. You can then set a repeat trigger to this channel and move it all the way to the left hand edge or 90% where data will seemingly scroll till you hit a button to create the pulse and then the buffer will complete and then move to the next one.

Another option is using the same technique but apply a mask to the pulse channel. By setting up the mask around the idle signal, an action can be applied so that as soon as the mask is interrupted by the pulse you can get the software to do a number of things such as save all the data, stop the capture and if you are using the latest Early Access build of PicoScope 7 Automotive you can export the decode table. You can see more on this in the following post - viewtopic.php?p=105013#p105013.
Export decode table action.png
Please be careful with actions and the events Every capture and Buffer full. If not set up correctly they will continue to save data and potentially fill your hard drive.

I hope this helps

Kind regards

Ben

Bruno.Carreira
Newbie
Posts: 3
Joined: Thu Feb 08, 2024 11:26 am

Re: Hitachi ZW220-7

Post by Bruno.Carreira »

Thank you for your support.
Which waveform should I expect from a "abnormal update rate" in the nox sensor?
Regards
A good weekend for everyone!

Steve Smith
Pico Staff Member
Pico Staff Member
Posts: 1586
Joined: Sun Aug 25, 2013 7:22 am

Re: Hitachi ZW220-7

Post by Steve Smith »

Hello Bruno and thank you for the feedback

Following Ben’s advice and using the Guided Test configuration for J1939 decoding, we know that 0x51 [ID3 Source Address] is NOx sensor 1 with a transmission rate of 50 ms

With this knowledge we can now use the search feature in the decode table to search for 0x51 and monitor the transmission rate

Below I have used “Wheel Speed” as an example by searching for ID2 (PGN) 65265 where we can see a transmission rate of 100 ms
1
1
By clicking on any of the packets in the decode table we are immediately directed to the packet in the graph view where we can view the structure of the signal and analyse for any irregularities

With your machine you would use the same technique but search for 51 within the [ID3 Source Address] column where you can quickly assess the transmission rate (50 ms)

Below is the search feature to use which returns no results as 51 does not exist in our Guided Test file
2
2
Where you now have a series of NOx sensor 1 or 2 with an abnormal update rate/ “babbling” you can detect these events in the decode table as they will occur more frequent than 50 ms

Clicking on one such babbling event in the decode table will take you directly to the offending packet in the graph view

At this stage, it would be good to view the differences in structure of the CAN packet between events where the NOx sensor is transmitting at the correct rate, and when babbling

I hope this helps and please feedback for any clarification

Take care…..Steve

Post Reply