DM1 Behavior on PV750

Discuss issues and ideas you have to configuring displays with PowerVision
tshiii
Posts: 79
Joined: Thu Sep 09, 2010 8:56 pm

DM1 Behavior on PV750

Post by tshiii » Thu Nov 15, 2012 12:50 am

Dear Sir,

The following DM1 code was detected (two times) on PV750 of a pleasure boat, but ECU does not output this DM1 code (the code is not set at the ECU). So, we do not know why the code was detected.

PORT, SPN 414896, FMI 0, SA150

Please kindly advise why the code was found? For example, is it possible for PV750 to rewrite a code due to some error?

Thank you and best regards,
Shiii
ksaenz
Enovation Controls Development
Enovation Controls Development
Posts: 263
Joined: Thu Aug 19, 2010 7:53 am

Re: DM1 Behavior on PV750

Post by ksaenz » Thu Nov 15, 2012 8:02 am

Hello Shiii,

SPN 414896 is not a standard SPN.
FMI 0 means data valid but above normal operational range.
Source Address 150 is not assigned to a specific type of device.

Do you know if there is a device with SA 150 on the Bus?

Can you look at a CAN log and see other messages coming from SA 150?

Thank you,

ksaenz
tshiii
Posts: 79
Joined: Thu Sep 09, 2010 8:56 pm

Re: DM1 Behavior on PV750

Post by tshiii » Mon Nov 26, 2012 10:17 pm

Hello Ksaenz,

Sorry for the delay in reply.

> Do you know if there is a device with SA 150 on the Bus?
Yes, there is an ECU for remote control with SA 150.

> Can you look at a CAN log and see other messages coming from SA 150?
The CAN log could not be confirmed because of no repeatability. Shift Position and Throttle Position are coming from SA 150.

Would you also advise what the sentence below means?
> Source Address 150 is not assigned to a specific type of device.

Thank you,
Shiii
ksaenz
Enovation Controls Development
Enovation Controls Development
Posts: 263
Joined: Thu Aug 19, 2010 7:53 am

Re: DM1 Behavior on PV750

Post by ksaenz » Tue Nov 27, 2012 8:57 am

In the J1939 standard some source addresses are assigned for specific devices:
0 = Engine #1
1 = Engine #2
2 = Turbocharger
3 = Transmission #1
etc..

But address 150 is not assigned so I couldn't deduce which device was sending the DTC.

Looks like that doesn't matter because you already know it is an ECU for remote control that sends Shift Position and Throttle Position.

Do you know if the PV750 has shown other DM1s coming from that device correctly?

Thank you,

ksaenz
tshiii
Posts: 79
Joined: Thu Sep 09, 2010 8:56 pm

Re: DM1 Behavior on PV750

Post by tshiii » Wed Nov 28, 2012 1:59 am

Hello Ksaenz,

Thank you for your prompt reply. I understand what you meant.

Yes, the PV750 has shown other DM1s coming from the device correctly.

Best regards,
Shiii
ksaenz
Enovation Controls Development
Enovation Controls Development
Posts: 263
Joined: Thu Aug 19, 2010 7:53 am

Re: DM1 Behavior on PV750

Post by ksaenz » Wed Nov 28, 2012 7:58 am

Ok, I was wondering if the DM1s needed to be decoded using a different conversion method but sounds like that is not the case.

The next thing I can think of is to log the CAN data to see if the DM1 message carries those SPN and FMI numbers or the PV750 just not parsed them correctly.

Regards,

ksaenz
mbowdich
Posts: 209
Joined: Tue Oct 05, 2010 10:54 am

Re: DM1 Behavior on PV750

Post by mbowdich » Wed Dec 05, 2012 11:11 pm

I have had a similar issue. Is the code random, and do you get other random codes? The issue I had was that one of the ECUs was not sending a full 8 byte DM1 message when there were no valid codes. It was sending a truncated 3 byte message instead (which is technically not allowed). The display (PV750 in my case) was expecting 8 bytes and was filling in the missing 5 bytes with whatever was the following 5 bytes of data on the CAN bus. This resulted in random DM1 alarms. I believe that Murphy patched it a while ago, though. We were able to get the ECU manufacturer to fix the DM1 message.

You may want to take a raw CAN capture and see if there are any truncated DM1 messages on the bus.
alb
Posts: 43
Joined: Wed Dec 15, 2010 1:30 pm

Re: DM1 Behavior on PV750

Post by alb » Tue Dec 18, 2012 12:14 pm

I've also seen nonsensical DM1 messages from a Cummins engine ECM on an unusual address, SA15 interfering with an FWMurphy XM500 on the same SA. The DM1s would pop up, then automatically clear a moment later. I believe this is because both devices were simultaneously transmitting multi-packet transport protocol messages with a destination address of FF and the packets were being intermixed. This would only be possible if a multi-packet DM1 xmit was initiated from the XM500 and then blended with a 2nd packet from the engine ECM carrying different information from a different PGN.