CAN bus transport implementation

[JeeLet]

The original idea was: how to check the status of the CAN bus.

. is there any dialogue ?
. are there any messages?

of course this can be done with MySensors.

But to get as close as possible to the communication channel (the CAN bus) I thought it was easy to do.

this is by reading the post of bricoleau here
text french
that the idea came to me.

• on the arduino have a blinking led to say that the CAN bus is out of order (but we forget, it loads the program unnecessarily)

and also because you suggested it to me
yes we have to beat the iron when it is hot, and my time available for the computer will soon be reduced (purchase and work of a house)

I appreciate very much your explanatory note, thank you

I activated the 16Mhz in the sketch, and put it back in the library

  #define MY_NODE_ID 57          /*Node en ID static*/

  #define MY_CAN
  #define CAN_CLOCK MCP_16MHZ

[Adam Slowik]

@JeeLet said in CAN bus transport implementation:

The original idea was: how to check the status of the CAN bus.
. is there any dialogue ?
. are there any messages?
of course this can be done with MySensors.
But to get as close as possible to the communication channel (the CAN bus) I thought it was easy to do.

That is something I can work with. I will check if used library provides some function to check bus status.

@JeeLet said in CAN bus transport implementation:

my time available for the computer will soon be reduced (purchase and work of a house)

I totally understand.

[Adam Slowik]

So library gives us 3 interesting functions:

INT8U checkError(void);           
INT8U errorCountRX(void);                                           
INT8U errorCountTX(void);   

Full description can be found in library source code and in documentation chapter 6:
https://ww1.microchip.com/downloads/en/DeviceDoc/MCP2515-Stand-Alone-CAN-Controller-with-SPI-20001801J.pdf

long story short:

1. INT8U checkError(void); returns:
   -CAN_CTRLERROR when things are bad or very bad
   -CAN_OK when things are ok or not so bad (error counters below 96)
   I would like to chage implementation of sanity check to something like this:

bool transportSanityCheck(void)
{
	return (CAN0.getError()==CAN_OK)
}

It won't blink diodes in case of communication problems, but will provide some feedback about communication to MySensors library.

2)INT8U errorCountRX(void); return error counter for received messages. AFAIK this counter is incremented when error occurs and decremented when message is received. I'm not a 'radio guy' but i think this could be returned as int16_t transportGetReceivingSNR(void) or int16_t transportGetReceivingRSSI(void). I know SNR and RSSI are radio related parameters, but perhaps We could bend the border here. Maybe some 'radio guy' could say something about this idea?

3)INT8U errorCountTX(void); same situation as with #2. 'Radio guy' opinion would by great.

Again ideas #2 and #3 are not solving problems, but providing feedback to MySensors.

Are My ideas ok, or do they do not pass sanityCheck() :)

[JeeLet]

"Are my ideas good" .. yes yes c'est tout bon

"It will not flash the diodes in case of communication problems" ... it's not a problem, Christmas is still far :)

But yes a counter that increments is a good thing.

what do you want me to test ????

bool transportSanityCheck(void)
{
	return (CAN0.getError()==CAN_OK)
}

The "radio guy" opinion would be great.
((I'll look for possible help ). )

Re-Edit

hal/transport/CAN/MyTransportCAN.cpp

bool transportSanityCheck(void)
{
	// not implemented yet
	return true;
}

:stuck_out_tongue_winking_eye:

Edit
I searched the web, and using SNR RSSI with the CAN bus is a dead end.
https://www.thethingsnetwork.org/docs/lorawan/rssi-and-snr/

[JeeLet]

.. bip bip

[Adam Slowik]

Are You still have an issue when MY_DEBUG is deactivated? Have You tried to add delay as is was suggested in one of the threads You found?

[JeeLet]

sorry for the alert.

it was an error in the gateway sketch

a ... #define MY_WITH_LEDS_BLINKING_INVERSE... duplicate, is misplaced

désolé

go to a fourth node
(Gw0 - Nodes 55 56 57 58 )

[JeeLet]

hello

did you find some time to add the CAN bus error feedback?

the 2 and 3 is good, enough :dancer:

and give me the procedure for the sketch :)

[virtualmkr]

@Adam-Slowik, @JeeLet
Ok, I will give CAN-Bus a try. This is my test setup:

I will use the demo sketches from Adam's fork. Let you know how it works for me.

[virtualmkr]

@JeeLet

what do you want me to test ????

bool transportSanityCheck(void)
{
	return (CAN0.getError()==CAN_OK)
}

The "radio guy" opinion would be great.
((I'll look for possible help ). )

I'm not a "radio guy", but I think this code change looks fine. When sanity check fails then MySensors core calls transportInit() which would try to re-initialise the MCP2515 module.

In my setup with only 2 CAN modules I'm afraid this will always return CAN_OK. So no idea how to check this. May be unplug the both CAN wires?

[virtualmkr]

@Adam-Slowik, @JeeLet Ok, with the both sketches it works with some limitations.
Nice work so far - thank you for contributing!

I have done some modifications in the CAN transport files.
@Adam-Slowik I would like to create a PR in your forked repo. Then we can discuss the code changes in GitHub. Would that be Ok for you - do you have time for this?

One limitation I found so far are long MyMessages. They can be up to 32 byte - which results in up to 4 CAN-Bus sub telegrams. When I send 32 byte message I observed the sub telegrams do not always arrive in send order in MyTransportCAN.cpp like this:

19916 CAN:RCV:CANH=2202010368,ID=3,TOTAL=4,CURR=0,TO=3,FROM=0
19921 CAN:RCV:LN=8,DTA0=0,DTA1=0,DTA2=3,DTA3=202,DTA4=9,DTA5=2,DTA6=0,DTA7=49
19929 CAN:RCV:SLOT=0,PART=1
19932 CAN:RCV:CANH=2202075904,ID=3,TOTAL=4,CURR=1,TO=3,FROM=0
19937 CAN:RCV:LN=8,DTA0=50,DTA1=51,DTA2=52,DTA3=53,DTA4=54,DTA5=55,DTA6=56,DTA7=57
19945 CAN:RCV:SLOT=0,PART=2
19947 CAN:RCV:CANH=2202206976,ID=3,TOTAL=4,CURR=3,TO=3,FROM=0
19953 CAN:RCV:LN=8,DTA0=56,DTA1=57,DTA2=48,DTA3=49,DTA4=50,DTA5=51,DTA6=52,DTA7=53
19960 !CAN:RCV:proper slot not found
19964 CAN:RCV:CANH=2202141440,ID=3,TOTAL=4,CURR=2,TO=3,FROM=0
19970 CAN:RCV:LN=8,DTA0=48,DTA1=49,DTA2=50,DTA3=51,DTA4=52,DTA5=53,DTA6=54,DTA7=55
19978 CAN:RCV:SLOT=0,PART=3

Sub telegram 3 arrives before 2.
I'm afraid the function _findCanPacketSlot() needs an update to handle this.
@Adam-Slowik Do you see a chance for you to update the logic next time?

Other limitation I see is the limited CAN telegram buffer of 3 packets in the MCP2515 module. I'm afraid for reliable operation with MySensors a change from polling to interrupt mode is required.
But this can be done later, after the fix for the PacketSlot logic.

[virtualmkr]

In logic analyser it looks like this:

Upper 4 channels are from node, lower ones are from gateway.

Close up from gateway send (4 packets):

[Adam Slowik]

@virtualmkr said in CAN bus transport implementation:

I'm not a "radio guy", but I think this code change looks fine. When sanity check fails then MySensors core calls transportInit() which would try to re-initialise the MCP2515 module.

Ok. I'll update code.

@virtualmkr said in CAN bus transport implementation:

I have done some modifications in the CAN transport files.
@Adam-Slowik I would like to create a PR in your forked repo. Then we can discuss the code changes in GitHub. Would that be Ok for you - do you have time for this?

Sure. Make PR. I'll try to review it within 48h.

@virtualmkr said in CAN bus transport implementation:

When I send 32 byte message I observed the sub telegrams do not always arrive in send order

Other limitation I see is the limited CAN telegram buffer of 3 packets in the MCP2515 module. I'm afraid for reliable operation with MySensors a change from polling to interrupt mode is required.

I think this two issues are linked. Now packets are sent in correct order (could You verify it?). If packets are sent in short periods We should use interrupt to keep MCP2515 buffers empty. When We fail to keep buffers empty (due to polling mechanism) We receive sub telegrams in mixed order. This theory could be true if MCP2515 buffers are implemented as LIFO. I'll look into documentation to figure it out.
Anyway both fixes are worth to implement. I'll try to do this over weekend.

[JeeLet]

Hello
CAN Bus is still functional, and no problem.

a question : is it possible to implement the use of 2 CAN Module on the same Gateway.
2 CAN bus or RS485 + CAN

as for the RS485 in example for a Mega2560 board

MyConfig.h
......
 * Example: @code #define MY_RS485_HWSERIAL Serial1 @endcode
 */
//#define MY_RS485_HWSERIAL (Serial1)