J1939 Interpacket Delay

J1939 Interpacket Delay

[swapnil]

Hi All,

        Hey Kurt I am using the J1939 stack on begalbone 
I am halfway through. I am getting some issue while testing with different 
engine control modules

1. Is it possible to add inter packet delay in 2 frames. Now the gap between 
two frame is 540 to 555 uSec which is very fast. My other engine control 
module is not that fast ..
    please check the Log 
1387762862.278774) can0 18EC00F9#104906E6E600EF00
(1387762862.279388) can0 18ECF900#11E601FFFF00EF00
(1387762862.280160) can0 18EB00F9#014D000010800000
(1387762862.280705) can0 18EB00F9#020640FB05FFFFFF
(1387762862.281284) can0 18EB00F9#03FFFFFF00000000
                        .
                        .
                        .  
(1387762862.566022) can0 18EB00F9#E45F4D0000000841
(1387762862.566574) can0 18EB00F9#E55850325F4E0000
(1387762862.567091) can0 18EB00F9#E6000841585431
(1387762863.822072) can0 18EC00F9#FF03FFFFFF00EF00

The other End is not sending message if i use adapter It receive EOM
   i want to make difference between to packet is 600uSec


2.if There is only one device connected on the bus like Begalbone(address -
f9) and Engine control module(address -00) 
     if i send a message to address 01 or 02 on can bus i see message for 01 
is converted to address 00 
like i amsending 18EF01F9#FF000000000002FF
but in candump i got
(1387762810.854139) can0 18EF00F9#FA000000000002FF
(1387762810.854762) can0 18EFF900#FB0000024733FFFF

Thank You 

Re: J1939 Interpacket Delay

[Kurt Van Dijck]

Hey,

Part 1 of the answer...

On Wed, Apr 09, 2014 at 02:17:11PM +0000, swapnil wrote:
> Hi All,
> 
>         Hey Kurt I am using the J1939 stack on begalbone 
> I am halfway through. I am getting some issue while testing with different 
> engine control modules
> 
> 1. Is it possible to add inter packet delay in 2 frames. Now the gap between 
> two frame is 540 to 555 uSec which is very fast. My other engine control 
> module is not that fast ..

You're ECU supports transport protocol with flow control, but cannot
hanle back-to-back CAN frames?
That is weird at least.
The requirements are orthogonal. Fast vs. not too fast.

That is beyond j1939, and I did not integrate any support for such usecase.

>     please check the Log 
> 1387762862.278774) can0 18EC00F9#104906E6E600EF00
> (1387762862.279388) can0 18ECF900#11E601FFFF00EF00
> (1387762862.280160) can0 18EB00F9#014D000010800000
> (1387762862.280705) can0 18EB00F9#020640FB05FFFFFF
> (1387762862.281284) can0 18EB00F9#03FFFFFF00000000
>                         .
>                         .
>                         .  
> (1387762862.566022) can0 18EB00F9#E45F4D0000000841
> (1387762862.566574) can0 18EB00F9#E55850325F4E0000
> (1387762862.567091) can0 18EB00F9#E6000841585431
> (1387762863.822072) can0 18EC00F9#FF03FFFFFF00EF00
> 
> The other End is not sending message if i use adapter It receive EOM
>    i want to make difference between to packet is 600uSec

I tend to believe that this can be solved with traffic shaping
on CAN, regardless of CAN.

But I'm not very familiar with traffic shaping. Oliver?

Kind regards,
Kurt

Re: J1939 Interpacket Delay

[Kurt Van Dijck]

Hey,

part 2 ...

On Wed, Apr 09, 2014 at 02:17:11PM +0000, swapnil wrote:
> Hi All,
> 
>         Hey Kurt I am using the J1939 stack on begalbone 
> I am halfway through. I am getting some issue while testing with different 
> engine control modules
> 

[...]

> 
> 2.if There is only one device connected on the bus like Begalbone(address -
> f9) and Engine control module(address -00) 
>      if i send a message to address 01 or 02 on can bus i see message for 01 
> is converted to address 00 
> like i amsending 18EF01F9#FF000000000002FF
> but in candump i got
> (1387762810.854139) can0 18EF00F9#FA000000000002FF
> (1387762810.854762) can0 18EFF900#FB0000024733FFFF

Are you sure you send 18EF01F9?
Can you show the output of "ip addr show can0" & "ip link show can0"?
Maybe that gives me a clue.

Kind regards,
Kurt

Re: J1939 Interpacket Delay

[swapnil]

Kurt Van Dijck <dev.kurt <at> vandijck-laurijssen.be> writes:

> 
> Hey,
> 
> part 2 ...
> 
> On Wed, Apr 09, 2014 at 02:17:11PM +0000, swapnil wrote:
> > Hi All,
> > 
> >         Hey Kurt I am using the J1939 stack on begalbone 
> > I am halfway through. I am getting some issue while testing with 
different 
> > engine control modules
> > 
> 
> [...]
> 
> > 
> > 2.if There is only one device connected on the bus like 
Begalbone(address -
> > f9) and Engine control module(address -00) 
> >      if i send a message to address 01 or 02 on can bus i see message 
for 01 
> > is converted to address 00 
> > like i amsending 18EF01F9#FF000000000002FF
> > but in candump i got
> > (1387762810.854139) can0 18EF00F9#FA000000000002FF
> > (1387762810.854762) can0 18EFF900#FB0000024733FFFF
> 
> Are you sure you send 18EF01F9?
> Can you show the output of "ip addr show can0" & "ip link show can0"?
> Maybe that gives me a clue.

ubuntu@arm:~/can-j1939-utils$ ip addr show can0
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 
10
    link/can
    can-j1939 0xf9 scope link

ubuntu@arm:~/can-j1939-utils$ ip link show can0
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 
10
    link/can
    j1939 on

I am transmitting   00112233445566 from F9 to 01

on ./candump -L can0
(1387763283.287747) can0 18EF00F9#00112233445566


> Kind regards,
> Kurt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: J1939 Interpacket Delay

[swapnil]

Kurt Van Dijck <dev.kurt <at> vandijck-laurijssen.be> writes:

> 
> Hey,
> 
> Part 1 of the answer...
> 
> On Wed, Apr 09, 2014 at 02:17:11PM +0000, swapnil wrote:
> > Hi All,
> > 
> >         Hey Kurt I am using the J1939 stack on begalbone 
> > I am halfway through. I am getting some issue while testing with 
different 
> > engine control modules
> > 
> > 1. Is it possible to add inter packet delay in 2 frames. Now the gap 
between 
> > two frame is 540 to 555 uSec which is very fast. My other engine control 
> > module is not that fast ..
> 
> You're ECU supports transport protocol with flow control, but cannot
> hanle back-to-back CAN frames?
> That is weird at least.
> The requirements are orthogonal. Fast vs. not too fast.
> 
> That is beyond j1939, and I did not integrate any support for such 
usecase.
> 
> >     please check the Log 
> > 1387762862.278774) can0 18EC00F9#104906E6E600EF00
> > (1387762862.279388) can0 18ECF900#11E601FFFF00EF00
> > (1387762862.280160) can0 18EB00F9#014D000010800000
> > (1387762862.280705) can0 18EB00F9#020640FB05FFFFFF
> > (1387762862.281284) can0 18EB00F9#03FFFFFF00000000
> >                         .
> >                         .
> >                         .  
> > (1387762862.566022) can0 18EB00F9#E45F4D0000000841
> > (1387762862.566574) can0 18EB00F9#E55850325F4E0000
> > (1387762862.567091) can0 18EB00F9#E6000841585431
> > (1387762863.822072) can0 18EC00F9#FF03FFFFFF00EF00
> > 
> > The other End is not sending message if i use adapter It receive EOM
> >    i want to make difference between to packet is 600uSec
> 
> I tend to believe that this can be solved with traffic shaping
> on CAN, regardless of CAN.
> 
> But I'm not very familiar with traffic shaping. Oliver?
I will keep searching on how to use this option (traffic shaping) for can
Is it possible that i can modify the code for j1939 for adding some delay 
for my use only -- if yes
can u tell in which function can i add that delay.
This is the most important part in my project.. actually i am able to 
monitor the parameters using j1939 stack but if i want to calibrate ECU
it fails.

Re: J1939 Interpacket Delay

[Kurt Van Dijck]

Hey,

> > Hey,
> > 
> > Part 1 of the answer...
> > 
> > On Wed, Apr 09, 2014 at 02:17:11PM +0000, swapnil wrote:
> > > Hi All,
> > > 
> > >         Hey Kurt I am using the J1939 stack on begalbone 
> > > I am halfway through. I am getting some issue while testing with 
> different 
> > > engine control modules
> > > 
> > > 1. Is it possible to add inter packet delay in 2 frames. Now the gap 
> between 
> > > two frame is 540 to 555 uSec which is very fast. My other engine control 
> > > module is not that fast ..
> > 
> > You're ECU supports transport protocol with flow control, but cannot
> > hanle back-to-back CAN frames?
> > That is weird at least.
> > The requirements are orthogonal. Fast vs. not too fast.
> > 
> > That is beyond j1939, and I did not integrate any support for such 
> usecase.
> > > 
[...]
> > > The other End is not sending message if i use adapter It receive EOM
> > >    i want to make difference between to packet is 600uSec
> > 
> > I tend to believe that this can be solved with traffic shaping
> > on CAN, regardless of CAN.
> > 
> > But I'm not very familiar with traffic shaping. Oliver?
> I will keep searching on how to use this option (traffic shaping) for can
> Is it possible that i can modify the code for j1939 for adding some delay 
> for my use only -- if yes

yes, you can. It's GPL

> can u tell in which function can i add that delay.
> This is the most important part in my project..

You can patch the code like shown below.
If that helps you releasing a product, don't hesitate.

I'll keep your usecase in mind for the future.

> actually i am able to 
> monitor the parameters using j1939 stack but if i want to calibrate ECU
> it fails.

in net/can/j1939/transport.c, around line 1046, add this.

	case tp_cmd_bam:
		...
		while (session->pkt.tx < pkt_end) {
			...
			if (j1939cb_is_broadcast(session->cb)) {
				if (session->pkt.tx < session->pkt.total)
					j1939tp_schedule_txtimer(session, 50);
				break;
+			} else {
+				j1939tp_schedule_txtimer(session, 1);
+				break;
			}
		}

this will add 1+ msec delay between packets.
You may need to use bigger delays, like 5msec, as this is the delay
that is used to schedule the packet into the queue, and you want to
delay the point that the CAN frames leave the queue onto the CAN bus.

Kurt

Re: J1939 Destination address corruption

[Kurt Van Dijck]

Hey,

On Thu, Apr 10, 2014 at 02:49:21AM +0000, swapnil wrote:
> Kurt Van Dijck <dev.kurt <at> vandijck-laurijssen.be> writes:
> 
> > 
> > Hey,
> > 
> > part 2 ...
> > 
> > On Wed, Apr 09, 2014 at 02:17:11PM +0000, swapnil wrote:
> > > Hi All,
> > > 
> > >         Hey Kurt I am using the J1939 stack on begalbone 
> > > I am halfway through. I am getting some issue while testing with 
> different 
> > > engine control modules
> > > 
> > 
> > [...]
> > 
> > > 
> > > 2.if There is only one device connected on the bus like 
> Begalbone(address -
> > > f9) and Engine control module(address -00) 
> > >      if i send a message to address 01 or 02 on can bus i see message 
> for 01 
> > > is converted to address 00 
> > > like i amsending 18EF01F9#FF000000000002FF
> > > but in candump i got
> > > (1387762810.854139) can0 18EF00F9#FA000000000002FF
> > > (1387762810.854762) can0 18EFF900#FB0000024733FFFF
> > 
> > Are you sure you send 18EF01F9?
> > Can you show the output of "ip addr show can0" & "ip link show can0"?
> > Maybe that gives me a clue.
> 
> ubuntu@arm:~/can-j1939-utils$ ip addr show can0
> 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 
> 10
>     link/can
>     can-j1939 0xf9 scope link
> 
> ubuntu@arm:~/can-j1939-utils$ ip link show can0
> 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 
> 10
>     link/can
>     j1939 on
> 
> I am transmitting   00112233445566 from F9 to 01
> 
> on ./candump -L can0
> (1387763283.287747) can0 18EF00F9#00112233445566

To be honest, I have no clue yet.
Can you verify the bind() & sendto() related code, so to make sure
you actually apply destination address 01?

Next stop would be to try my j1939 test program that I sent you earlier.

Kind regards,
Kurt

Re: J1939 Interpacket Delay

[swapnil]

Kurt Van Dijck <dev.kurt <at> vandijck-laurijssen.be> writes:

> 
> Hey,
> 
> > > Hey,
> > > 
> > > Part 1 of the answer...
> > > 
> > > On Wed, Apr 09, 2014 at 02:17:11PM +0000, swapnil wrote:
> > > > Hi All,
> > > > 
> > > >         Hey Kurt I am using the J1939 stack on begalbone 
> > > > I am halfway through. I am getting some issue while testing with 
> > different 
> > > > engine control modules
> > > > 
> > > > 1. Is it possible to add inter packet delay in 2 frames. Now the gap 
> > between 
> > > > two frame is 540 to 555 uSec which is very fast. My other engine 
control 
> > > > module is not that fast ..
> > > 
> > > You're ECU supports transport protocol with flow control, but cannot
> > > hanle back-to-back CAN frames?
> > > That is weird at least.
> > > The requirements are orthogonal. Fast vs. not too fast.
> > > 
> > > That is beyond j1939, and I did not integrate any support for such 
> > usecase.
> > > > 
> [...]
> > > > The other End is not sending message if i use adapter It receive EOM
> > > >    i want to make difference between to packet is 600uSec
> > > 
> > > I tend to believe that this can be solved with traffic shaping
> > > on CAN, regardless of CAN.
> > > 
> > > But I'm not very familiar with traffic shaping. Oliver?
> > I will keep searching on how to use this option (traffic shaping) for 
can
> > Is it possible that i can modify the code for j1939 for adding some 
delay 
> > for my use only -- if yes
> 
> yes, you can. It's GPL
> 
> > can u tell in which function can i add that delay.
> > This is the most important part in my project..
> 
> You can patch the code like shown below.
> If that helps you releasing a product, don't hesitate.
> 
> I'll keep your usecase in mind for the future.
> 
> > actually i am able to 
> > monitor the parameters using j1939 stack but if i want to calibrate ECU
> > it fails.
> 
> in net/can/j1939/transport.c, around line 1046, add this.
> 
> 	case tp_cmd_bam:
> 		...
> 		while (session->pkt.tx < pkt_end) {
> 			...
> 			if (j1939cb_is_broadcast(session->cb)) {
> 				if (session->pkt.tx < session->pkt.total)
> 					j1939tp_schedule_txtimer(session, 
50);
> 				break;
> +			} else {
> +				j1939tp_schedule_txtimer(session, 1);
> +				break;
> 			}
> 		}
> 
> this will add 1+ msec delay between packets.
> You may need to use bigger delays, like 5msec, as this is the delay
> that is used to schedule the packet into the queue, and you want to
> delay the point that the CAN frames leave the queue onto the CAN bus.
> 
> Kurt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Thanks Kurt i merged this change and it is showing delay of 1 ms in each 
packet from my test program .I will try this on ECU.
log from candump
1387768377.823498) can0 18EC00F9#10B2001A1A00EF00
(1387768377.824306) can0 1CECF900#111A01FFFF00EF00
(1387768377.825045) can0 18EB00F9#0100112233445566
(1387768377.826136) can0 18EB00F9#0200112233445566
(1387768377.827230) can0 18EB00F9#0300112233445566
(1387768377.828566) can0 18EB00F9#0400112233445566
(1387768377.829635) can0 18EB00F9#0544556600112233
(1387768377.830779) can0 18EB00F9#0644556644556600
(1387768377.831878) can0 18EB00F9#0711223344556644
(1387768377.832988) can0 18EB00F9#0855660011223344
(1387768377.834063) can0 18EB00F9#0955664455660011
(1387768377.835134) can0 18EB00F9#0A22334455664455
(1387768377.836277) can0 18EB00F9#0B66001122334455
(1387768377.837373) can0 18EB00F9#0C66445566001122
(1387768377.838451) can0 18EB00F9#0D33445566445566
(1387768377.839655) can0 18EB00F9#0E00112233445566
(1387768377.840645) can0 18EB00F9#0F44556600112233
(1387768377.841721) can0 18EB00F9#1044556644556600
(1387768377.842796) can0 18EB00F9#1111223344556644
(1387768377.843926) can0 18EB00F9#1255660011223344
(1387768377.845020) can0 18EB00F9#1355664455660011
(1387768377.846148) can0 18EB00F9#1422334455664455
(1387768377.847236) can0 18EB00F9#1566001122334455
(1387768377.848366) can0 18EB00F9#1666445566001122
(1387768377.849429) can0 18EB00F9#1733445566445566
(1387768377.850531) can0 18EB00F9#1800112233445566
(1387768377.851619) can0 18EB00F9#1944556600112233
(1387768377.852570) can0 18EB00F9#1A445566
(1387768377.853316) can0 1CECF900#13B2001AFF00EF00
Thanks once again 

Re: J1939 Destination address corruption

[swapnil]

Kurt Van Dijck <dev.kurt <at> vandijck-laurijssen.be> writes:

> 
> Hey,
> 
> On Thu, Apr 10, 2014 at 02:49:21AM +0000, swapnil wrote:
> > Kurt Van Dijck <dev.kurt <at> vandijck-laurijssen.be> writes:
> > 
> > > 
> > > Hey,
> > > 
> > > part 2 ...
> > > 
> > > On Wed, Apr 09, 2014 at 02:17:11PM +0000, swapnil wrote:
> > > > Hi All,
> > > > 
> > > >         Hey Kurt I am using the J1939 stack on begalbone 
> > > > I am halfway through. I am getting some issue while testing with 
> > different 
> > > > engine control modules
> > > > 
> > > 
> > > [...]
> > > 
> > > > 
> > > > 2.if There is only one device connected on the bus like 
> > Begalbone(address -
> > > > f9) and Engine control module(address -00) 
> > > >      if i send a message to address 01 or 02 on can bus i see 
message 
> > for 01 
> > > > is converted to address 00 
> > > > like i amsending 18EF01F9#FF000000000002FF
> > > > but in candump i got
> > > > (1387762810.854139) can0 18EF00F9#FA000000000002FF
> > > > (1387762810.854762) can0 18EFF900#FB0000024733FFFF
> > > 
> > > Are you sure you send 18EF01F9?
> > > Can you show the output of "ip addr show can0" & "ip link show can0"?
> > > Maybe that gives me a clue.
> > 
> > ubuntu <at> arm:~/can-j1939-utils$ ip addr show can0
> > 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN 
qlen 
> > 10
> >     link/can
> >     can-j1939 0xf9 scope link
> > 
> > ubuntu <at> arm:~/can-j1939-utils$ ip link show can0
> > 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN 
qlen 
> > 10
> >     link/can
> >     j1939 on
> > 
> > I am transmitting   00112233445566 from F9 to 01
> > 
> > on ./candump -L can0
> > (1387763283.287747) can0 18EF00F9#00112233445566
> 
> To be honest, I have no clue yet.
> Can you verify the bind() & sendto() related code, so to make sure
> you actually apply destination address 01?
> 
> Next stop would be to try my j1939 test program that I sent you earlier.
> 
> Kind regards,
> Kurt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
Yes, I think I am doing something wrong in my code not able to figure out 
yet .. 
Following is the output tested by your program which is working correct
 
Following is the output from j1939 test program that u send
00 is the address of other device on the bus 
message broadcast by that device is 
1.(1387769780.206999) can0 18EEFF00#1122334444332211 address claim request 
on candump

2. can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN 
qlen10      
    link/can
    can-j1939 0xf9 scope link  address claimed by begalbone ( can_j1939 
linux module)

3.root@arm:/home/ubuntu/can-j1939-utils# ./testj1939 -s20 can0:0xf9 
:0x00,0x12300
- socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
- bind(, can0:f9,,, 24);
- sendto(, <dat>, 20, 0, :00,12300,, 24);
  candump log
(1387770757.753292) can0 18EC00F9#1014000303002301
(1387770757.754066) can0 1CECF900#110301FFFF002301
(1387770757.754829) can0 18EB00F9#0100000000010000
(1387770757.755900) can0 18EB00F9#020050ACFBB60000
(1387770757.756985) can0 18EB00F9#03000000000000
(1387770757.757681) can0 1CECF900#13140003FF002301

4.root@arm:/home/ubuntu/can-j1939-utils# ./testj1939 -s20 can0:0xf9 
:0x90,0x12300
- socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
- bind(, can0:f9,,, 24);
- sendto(, <dat>, 20, 0, :90,12300,, 24);
(1387770765.594972) can0 18EC90F9#1014000303002301
(1387770766.850045) can0 18EC90F9#FF03FFFFFF002301

Thanks for suggestion to test with ur code 
  Hens forth i will test it with ur code before sending

****
can u share the document on how to set filters.
right now i am using my code for filtering the pgn and da
I tried to use the filters but failed as i am not sure how to set them..

Thank You,
Swapnil 

Re: J1939 Interpacket Delay

[Kurt Van Dijck]

On Thu, Apr 17, 2014 at 03:18:44AM +0000, swapnil wrote:
> Kurt Van Dijck <dev.kurt <at> vandijck-laurijssen.be> writes:
> 
> > 
> > Hey,
> > 
> > > > Hey,
> > > > 
[...]
> > > Is it possible that i can modify the code for j1939 for adding some 
> delay 
> > > for my use only -- if yes
> > 
> > yes, you can. It's GPL
> > 
> > > can u tell in which function can i add that delay.
> > > This is the most important part in my project..
> > 
> > You can patch the code like shown below.
> > If that helps you releasing a product, don't hesitate.
> > 
> > I'll keep your usecase in mind for the future.
> > 
> > > actually i am able to 
> > > monitor the parameters using j1939 stack but if i want to calibrate ECU
> > > it fails.
> > 
> > in net/can/j1939/transport.c, around line 1046, add this.
> > 
> > 	case tp_cmd_bam:
> > 		...
> > 		while (session->pkt.tx < pkt_end) {
> > 			...
> > 			if (j1939cb_is_broadcast(session->cb)) {
> > 				if (session->pkt.tx < session->pkt.total)
> > 					j1939tp_schedule_txtimer(session, 
> 50);
> > 				break;
> > +			} else {
> > +				j1939tp_schedule_txtimer(session, 1);
> > +				break;
> > 			}
> > 		}
> > 
> > this will add 1+ msec delay between packets.
> > You may need to use bigger delays, like 5msec, as this is the delay
> > that is used to schedule the packet into the queue, and you want to
> > delay the point that the CAN frames leave the queue onto the CAN bus.
> > 
> 
> Thanks Kurt i merged this change and it is showing delay of 1 ms in each 
> packet from my test program .I will try this on ECU.
> log from candump
> 1387768377.823498) can0 18EC00F9#10B2001A1A00EF00
> (1387768377.824306) can0 1CECF900#111A01FFFF00EF00
> (1387768377.825045) can0 18EB00F9#0100112233445566
> (1387768377.826136) can0 18EB00F9#0200112233445566
> (1387768377.827230) can0 18EB00F9#0300112233445566
> (1387768377.828566) can0 18EB00F9#0400112233445566
> (1387768377.829635) can0 18EB00F9#0544556600112233
> (1387768377.830779) can0 18EB00F9#0644556644556600
> (1387768377.831878) can0 18EB00F9#0711223344556644
> (1387768377.832988) can0 18EB00F9#0855660011223344
> (1387768377.834063) can0 18EB00F9#0955664455660011
> (1387768377.835134) can0 18EB00F9#0A22334455664455
> (1387768377.836277) can0 18EB00F9#0B66001122334455
> (1387768377.837373) can0 18EB00F9#0C66445566001122
> (1387768377.838451) can0 18EB00F9#0D33445566445566
> (1387768377.839655) can0 18EB00F9#0E00112233445566
> (1387768377.840645) can0 18EB00F9#0F44556600112233
> (1387768377.841721) can0 18EB00F9#1044556644556600
> (1387768377.842796) can0 18EB00F9#1111223344556644
> (1387768377.843926) can0 18EB00F9#1255660011223344
> (1387768377.845020) can0 18EB00F9#1355664455660011
> (1387768377.846148) can0 18EB00F9#1422334455664455
> (1387768377.847236) can0 18EB00F9#1566001122334455
> (1387768377.848366) can0 18EB00F9#1666445566001122
> (1387768377.849429) can0 18EB00F9#1733445566445566
> (1387768377.850531) can0 18EB00F9#1800112233445566
> (1387768377.851619) can0 18EB00F9#1944556600112233
> (1387768377.852570) can0 18EB00F9#1A445566
> (1387768377.853316) can0 1CECF900#13B2001AFF00EF00
> Thanks once again 

I'm glad it works as expected!

I'll investigate to add a decent API to control such thing from userspace
via sockets, some day.

Kind regards,
Kurt

Re: J1939 Destination address corruption

[Kurt Van Dijck]

On Thu, Apr 17, 2014 at 03:39:35AM +0000, swapnil wrote:
> Kurt Van Dijck <dev.kurt <at> vandijck-laurijssen.be> writes:
> 
> > 
> > Hey,
> > 
> > On Thu, Apr 10, 2014 at 02:49:21AM +0000, swapnil wrote:
> > > Kurt Van Dijck <dev.kurt <at> vandijck-laurijssen.be> writes:
> > > 
> > > > 
> > > > Hey,
> > > > 
> > > > part 2 ...
> > > > 
> > > > On Wed, Apr 09, 2014 at 02:17:11PM +0000, swapnil wrote:
> > > > > Hi All,
> > > > > 
> > > > >         Hey Kurt I am using the J1939 stack on begalbone 
> > > > > I am halfway through. I am getting some issue while testing with 
> > > different 
> > > > > engine control modules
> > > > > 
> > > > 
> > > > [...]
> > > > 
> > > > > 
> > > > > 2.if There is only one device connected on the bus like 
> > > Begalbone(address -
> > > > > f9) and Engine control module(address -00) 
> > > > >      if i send a message to address 01 or 02 on can bus i see 
> message 
> > > for 01 
> > > > > is converted to address 00 
> > > > > like i amsending 18EF01F9#FF000000000002FF
> > > > > but in candump i got
> > > > > (1387762810.854139) can0 18EF00F9#FA000000000002FF
> > > > > (1387762810.854762) can0 18EFF900#FB0000024733FFFF
> > > > 
> > > > Are you sure you send 18EF01F9?
> > > > Can you show the output of "ip addr show can0" & "ip link show can0"?
> > > > Maybe that gives me a clue.
> > > 
> > > ubuntu <at> arm:~/can-j1939-utils$ ip addr show can0
> > > 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN 
> qlen 
> > > 10
> > >     link/can
> > >     can-j1939 0xf9 scope link
> > > 
> > > ubuntu <at> arm:~/can-j1939-utils$ ip link show can0
> > > 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN 
> qlen 
> > > 10
> > >     link/can
> > >     j1939 on
> > > 
> > > I am transmitting   00112233445566 from F9 to 01
> > > 
> > > on ./candump -L can0
> > > (1387763283.287747) can0 18EF00F9#00112233445566
> > 
> > To be honest, I have no clue yet.
> > Can you verify the bind() & sendto() related code, so to make sure
> > you actually apply destination address 01?
> > 
> > Next stop would be to try my j1939 test program that I sent you earlier.
> > 
> > Kind regards,
> > Kurt
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-can" in
> > the body of a message to majordomo <at> vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > 
> Yes, I think I am doing something wrong in my code not able to figure out 
> yet .. 
> Following is the output tested by your program which is working correct
>  
> Following is the output from j1939 test program that u send
> 00 is the address of other device on the bus 
> message broadcast by that device is 
> 1.(1387769780.206999) can0 18EEFF00#1122334444332211 address claim request 
> on candump
> 
> 2. can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN 
> qlen10      
>     link/can
>     can-j1939 0xf9 scope link  address claimed by begalbone ( can_j1939 
> linux module)
> 
> 3.root@arm:/home/ubuntu/can-j1939-utils# ./testj1939 -s20 can0:0xf9 
> :0x00,0x12300
> - socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
> - bind(, can0:f9,,, 24);
> - sendto(, <dat>, 20, 0, :00,12300,, 24);
>   candump log
> (1387770757.753292) can0 18EC00F9#1014000303002301
> (1387770757.754066) can0 1CECF900#110301FFFF002301
> (1387770757.754829) can0 18EB00F9#0100000000010000
> (1387770757.755900) can0 18EB00F9#020050ACFBB60000
> (1387770757.756985) can0 18EB00F9#03000000000000
> (1387770757.757681) can0 1CECF900#13140003FF002301
> 
> 4.root@arm:/home/ubuntu/can-j1939-utils# ./testj1939 -s20 can0:0xf9 
> :0x90,0x12300
> - socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
> - bind(, can0:f9,,, 24);
> - sendto(, <dat>, 20, 0, :90,12300,, 24);
> (1387770765.594972) can0 18EC90F9#1014000303002301
> (1387770766.850045) can0 18EC90F9#FF03FFFFFF002301
> 
> Thanks for suggestion to test with ur code 
>   Hens forth i will test it with ur code before sending

You're welcome.
2 brains know more than 1 :-)

> 
> ****
> can u share the document on how to set filters.
> right now i am using my code for filtering the pgn and da
> I tried to use the filters but failed as i am not sure how to set them..

jacd.c in can-utils-j1939 contains an example of PGN filtering.
DA filtering is not supported, since only messages for your node
will be received through a socket, i.e. messages with your SA in DA,
or broadcasted messages.

You can do SA filtering, which works similarly to PGN filtering.
Just take a look at struct j1939_filter.

Kind regards,
Kurt

Re: J1939 Interpacket Delay - issue of EOM

[swapnil]

Kurt Van Dijck <dev.kurt <at> vandijck-laurijssen.be> writes:

> 
> On Thu, Apr 17, 2014 at 03:18:44AM +0000, swapnil wrote:
> > Kurt Van Dijck <dev.kurt <at> vandijck-laurijssen.be> writes:
> > 
> > > 
> > > Hey,
> > > 
> > > > > Hey,
> > > > > 
> [...]
> > > > Is it possible that i can modify the code for j1939 for adding some 
> > delay 
> > > > for my use only -- if yes
> > > 
> > > yes, you can. It's GPL
> > > 
> > > > can u tell in which function can i add that delay.
> > > > This is the most important part in my project..
> > > 
> > > You can patch the code like shown below.
> > > If that helps you releasing a product, don't hesitate.
> > > 
> > > I'll keep your usecase in mind for the future.
> > > 
> > > > actually i am able to 
> > > > monitor the parameters using j1939 stack but if i want to calibrate 
ECU
> > > > it fails.
> > > 
> > > in net/can/j1939/transport.c, around line 1046, add this.
> > > 
> > > 	case tp_cmd_bam:
> > > 		...
> > > 		while (session->pkt.tx < pkt_end) {
> > > 			...
> > > 			if (j1939cb_is_broadcast(session->cb)) {
> > > 				if (session->pkt.tx < session->pkt.total)
> > > 					j1939tp_schedule_txtimer(session, 
> > 50);
> > > 				break;
> > > +			} else {
> > > +				j1939tp_schedule_txtimer(session, 1);
> > > +				break;
> > > 			}
> > > 		}
> > > 
> > > this will add 1+ msec delay between packets.
> > > You may need to use bigger delays, like 5msec, as this is the delay
> > > that is used to schedule the packet into the queue, and you want to
> > > delay the point that the CAN frames leave the queue onto the CAN bus.
> > > 
> > 
> > Thanks Kurt i merged this change and it is showing delay of 1 ms in each 
> > packet from my test program .I will try this on ECU.
> > log from candump
> > 1387768377.823498) can0 18EC00F9#10B2001A1A00EF00
> > (1387768377.824306) can0 1CECF900#111A01FFFF00EF00
> > (1387768377.825045) can0 18EB00F9#0100112233445566
> > (1387768377.826136) can0 18EB00F9#0200112233445566
> > (1387768377.827230) can0 18EB00F9#0300112233445566
> > (1387768377.828566) can0 18EB00F9#0400112233445566
> > (1387768377.829635) can0 18EB00F9#0544556600112233
> > (1387768377.830779) can0 18EB00F9#0644556644556600
> > (1387768377.831878) can0 18EB00F9#0711223344556644
> > (1387768377.832988) can0 18EB00F9#0855660011223344
> > (1387768377.834063) can0 18EB00F9#0955664455660011
> > (1387768377.835134) can0 18EB00F9#0A22334455664455
> > (1387768377.836277) can0 18EB00F9#0B66001122334455
> > (1387768377.837373) can0 18EB00F9#0C66445566001122
> > (1387768377.838451) can0 18EB00F9#0D33445566445566
> > (1387768377.839655) can0 18EB00F9#0E00112233445566
> > (1387768377.840645) can0 18EB00F9#0F44556600112233
> > (1387768377.841721) can0 18EB00F9#1044556644556600
> > (1387768377.842796) can0 18EB00F9#1111223344556644
> > (1387768377.843926) can0 18EB00F9#1255660011223344
> > (1387768377.845020) can0 18EB00F9#1355664455660011
> > (1387768377.846148) can0 18EB00F9#1422334455664455
> > (1387768377.847236) can0 18EB00F9#1566001122334455
> > (1387768377.848366) can0 18EB00F9#1666445566001122
> > (1387768377.849429) can0 18EB00F9#1733445566445566
> > (1387768377.850531) can0 18EB00F9#1800112233445566
> > (1387768377.851619) can0 18EB00F9#1944556600112233
> > (1387768377.852570) can0 18EB00F9#1A445566
> > (1387768377.853316) can0 1CECF900#13B2001AFF00EF00
> > Thanks once again 
> 
> I'm glad it works as expected!
> 
> I'll investigate to add a decent API to control such thing from userspace
> via sockets, some day.
> 
> Kind regards,
> Kurt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Hi Kurt ,

 I am able to find out why ECU is not sending the end of message (EOM)
its because i am not padding(or filling) the renaming bytes 
please check the log

without padding 
(1387768742.573470) can0 18EC00F9#100A00020200EF00
(1387768742.574075) can0 18ECF900#110201FFFF00EF00
(1387768742.574802) can0 18EB00F9#0100112233445566
(1387768742.575741) can0 18EB00F9#02778899
(1387768743.830696) can0 18EC00F9#FF03FFFFFF00EF00

with padding reply
(1387768780.530352) can0 18EC00F9#100E00020200EF00
(1387768780.530957) can0 18ECF900#110201FFFF00EF00
(1387768780.531675) can0 18EB00F9#0100112233445566
(1387768780.532752) can0 18EB00F9#0277889911223344
(1387768780.533427) can0 18ECF900#130E0002FF00EF00

following lines from sae j1939
5.10.4 Transport Protocol—Data Transfer Message (TP.DT)

Packetized Data (7 bytes). Note the last packet of a multipacket
Parameter Group may require less than 8 data bytes. The extra bytes
should be filled with FF.

is it good to add in j1939 module ? or in my application 

Thank You Swapnil

J1939 packet stuffing

[Kurt Van Dijck]

Hey,

On Mon, Apr 21, 2014 at 03:04:12PM +0000, swapnil wrote:
> 
> without padding 
> (1387768742.573470) can0 18EC00F9#100A00020200EF00
> (1387768742.574075) can0 18ECF900#110201FFFF00EF00
> (1387768742.574802) can0 18EB00F9#0100112233445566
> (1387768742.575741) can0 18EB00F9#02778899
> (1387768743.830696) can0 18EC00F9#FF03FFFFFF00EF00
> 
> with padding reply
> (1387768780.530352) can0 18EC00F9#100E00020200EF00
> (1387768780.530957) can0 18ECF900#110201FFFF00EF00
> (1387768780.531675) can0 18EB00F9#0100112233445566
> (1387768780.532752) can0 18EB00F9#0277889911223344
> (1387768780.533427) can0 18ECF900#130E0002FF00EF00
> 
> following lines from sae j1939
> 5.10.4 Transport Protocol—Data Transfer Message (TP.DT)
> 
> Packetized Data (7 bytes). Note the last packet of a multipacket
> Parameter Group may require less than 8 data bytes. The extra bytes
> should be filled with FF.
> 
> is it good to add in j1939 module ? or in my application 

I'm aware of this rule in the spec.
I had expected that no ECU would ever complain about
missing stuffer bytes, as this appear a little stupid to me.
We passed the Isobus certification with this DLC < 8 thing.

Since you encountered such ECU, I must change opinion a little bit.

The right place to fix is not in userspace, but in the j1939 module.
I'll propose a patch soon that adds a modules parameter.
I'm thinking about adding a socket option, but I didn't find time yet.

Can you elaborate a bit on the ECU's that you found that expose this
behaviour? Which ECU's, which manufacturer, does all ECU's you found
have this behaviour?

Kurt

Re: J1939 packet stuffing

[swapnil]

Hi Kurt,
    1.For time being i am doing change in user space as i need to start 
testing for multiple(example 6 ECU ) ECU connected on J1939.
    Once it et update in the can-j1939 module i will update it.
  
    2.Yes,the packet stuffing issue occurred with every ecu that i have 
tested .. These all ECU from same manufacturer used in US


Thank You,
Swapnil    

Re: J1939 packet stuffing

[Kurt Van Dijck]

Hey Swapnil,

On Wed, Apr 23, 2014 at 02:58:27AM +0000, swapnil wrote:
> 
> Hi Kurt,
>     1.For time being i am doing change in user space as i need to start 
> testing for multiple(example 6 ECU ) ECU connected on J1939.
>     Once it et update in the can-j1939 module i will update it.

Modifying userspace means adjusting the dlc, which I think may not ideal
for transport protocol.
Hence, I understand your situation, therefore please find below a
quick fix proposal, similar to the interpacket delay insertion earlier.

This patch will stuff _all_ CAN frames with 0xff up to 8 bytes.
This conforms more strictly to the spec

>   
>     2.Yes,the packet stuffing issue occurred with every ecu that i have 
> tested .. These all ECU from same manufacturer used in US

I see. They all originate from the same programmer.
Well, that's a strict programmer.

--
diff --git a/net/can/j1939/main.c b/net/can/j1939/main.c
index 7edf843..1479de4 100644
--- a/net/can/j1939/main.c
+++ b/net/can/j1939/main.c
@@ -156,7 +156,9 @@ static int j1939_send_can(struct sk_buff *skb)
 		canid |= ((sk_addr->pgn & 0x3ffff) << 8);
 
 	msg->can_id = canid;
-	msg->can_dlc = dlc;
+	if (dlc < 8)
+		memset(msg->data+dlc, 0xff, 8 - dlc);
+	msg->can_dlc = 8;
 
 	/* set net_device */
 	ret = -ENODEV;