RS485 Stress test

[napo7]

I'm also looking for a wired network...
I think, as @kimot said, that we cannot rely on "listen what I just said", since this just ensure that the message we did wanted to say was correctly put on the line, but it doesn't ensure us that it was correctly received !
Perhaps we should use collision AVOIDANCE (be sure that the line is free before speaking), but ALSO use ACKing system.

[LeoDesigner]

I know about mysensors ACK protocol feature, I was talking about small ACK packet with checksum as a confirmation of the received packet.
So basically the easiest way to improve current situation is to add ACK/CONFIRMATION packets to the existing library. Unfortunately I am really busy right now with main projects.

[hausinger]

@kimot

I'm very interested in your development.
What kind of can bus module are you using? I found 2 different modules for very less money. The very small module is called SN65HVD230 (controlled by serial rx, tx) and cost approximately 1,75$ from China. The other module with bigger size is called MCP2515 (controlled by spi) and cost approximately 1,26 $ from China. Both are very cheap.
What is you currently status in this case?
I'm planning to use it for my new house in some month.

Thank you

[pjr]

@kimot @hausinger could you open new topic about can bus transport implementation for MYS? I think there would be a lot of interest about it.

[kimot]

@pjr @hausinger

Ok.
New topic is here:

https://forum.mysensors.org/topic/5327/can-bus-transport-implementation-for-mys

[LeoDesigner]

One more idea regarding cheap collision detection on the bus.
We can almost eliminate collisions on the bus (should be almost no lost packets at all).
Before packet transmission we need to check the bus state during one first byte time using digitalRead(rxPin). In this case collision may occur very rarely, because time between bus checking and actual first byte sending is very short.
Also the code modification will be very small in current library.

[napo7]

Hi,

@LeoDesigner , that's the begining of a way avoiding collisions, but it's not sufficient :
The problem is that if two devices performs that check at exactly the same time (even if it's not so-probable, it can happen), they will start speaking at the same time !

A second step would require HANDLING (and not avoiding) collision : what can (what MUST) we do when two devices speak at the same time ?

That's where CAN drivers become interresting : we can use them on a "simili-RS485" bus : if two devices speak at the same time, the device speaking louder (understand, placing higher bits first...) will be overwriting what second device is saying. So, the first device (the one that is speaking "louder") will not see any problem, it will continue speaking, and the second one (which will see that his bits are not heard) will stop speaking, and try again a few milliseconds later !

[pjr]

So we need collision AVOIDANCE and DETECTION for (almost?)perfect solution?

AVOIDANCE:

• line checking ( digitalRead(rxPin) ) what @LeoDesigner suggested

DETECTION:

• "listening what I just said"?
• checksum at receiving end?
• perhaps similar "hw ACK reply" as the radio is using?

With most important nodes I could additionally use controllers ACK functionality.

[msmacs]

Hi all,
this is my first post and I would like to congratulate you for this wonderful site :-)
I am also interested in a wired network and I know that rs485 bus has some limitations.. but rs485 modules are also really cheap (and I have already bought a lot of them :laughing: ).

Just an idea to handling the bus.. why don't you use a different size for the first message that Leo propose to check the collision? The size should follow a priority: maximum priority for Controller/Gateway, less priority for Repeater, lower priority for Sensor nodes.
For example
3 start bytes - Controller/Gateway
2 start bytes - Repeater
1 start byte - Sensor Node
In this way if a sensor and the Gateway start sending the byte in the same time, the gateway wins.

This could help also with sensors that need high priority, for example alarms. In this case we only need to change the priority of the sensor that send the message (maybe with a new option on the send() command .. like the ack option).

Max

[LeoDesigner]

@pjr said:

So we need collision AVOIDANCE and DETECTION for (almost?)perfect solution?

AVOIDANCE:

• line checking ( digitalRead(rxPin) ) what @LeoDesigner suggested

DETECTION:

• "listening what I just said"?
• checksum at receiving end?
• perhaps similar "hw ACK reply" as the radio is using?

With most important nodes I could additionally use controllers ACK functionality.

I hope we will finally will come to the right most perfect solution.
Let me say first: I am not saying that we should use only raw RS485. CAN bus is very good idea too. It's good to have alternatives. We can get some ideas from CAN protocol also. I like challenges, and right now it's like a getting something good out from dirt cheap staff.

So, how about this procedure:
Before packet will be sent:

• Collision AVOIDANCE: listen rxPin for time of one byte + few bits symbol interval
  • if bus is free: wait random time ( few bit's interval, 5-7) and check the bus again
  • if bus is free: start transmission of the first byte (start of the packet marker).

Collision DETECTION could be reliable done only via CHECKSUM ACK (small confirmation packet once we are received the input packet).

I think it's should be really rare case when two nodes will start transmission at the same time in case if we will make this random wait interval. Actually IMHO, Ethernet protocol using something like this (randomness before start).

[pjr]

Is the AVOIDANCE part already there?
I think the "HW" CHECKSUM ACK could be nice addition.

[LeoDesigner]

@pjr
Yes the AVOIDANCE part is implemented, however it's not perfect yet.
We still have collisions during the first start packet byte.
I really hope to find some time to make necessary patches.

[kimot]

I am looking to current MyTransportRS485.cpp and it seems, that only one SOH is sent at start of message.

// Start of header by writing multiple SOH
for(byte w=0; w<1; w++) {
_dev.write(SOH);

original:

// Start of header by writing multiple SOH
for(byte w=0;w<ICSC_SOH_START_COUNT;w++) _dev->write(SOH);

When node will lose this start of message, whole message will be lost.
Multiple SOHs can helps bus synchronization for software serial.

[LeoDesigner]

@kimot
I am absolutely agree about the number of SOH bytes.
Currently in my github code I am using:

//The number of SOH to start a message
//some device like Raspberry was missing the first SOH
//Increase or decrease the number to your needs

#define ICSC_SOH_START_COUNT 3

We need to ask someone to make minor changes to the MyTransportRS485.cpp or submit PR to the MyTransportRS485.cpp.

[Reza]

@AWI do you test with wire longer than 1 or 2 meter ? this is dont work .
19200 boud rate is best for 15cm.but can not work with long wire....

[AWI]

@Reza I think I had more than 5 meter in between, but I disassembled the circuit for now. Did you connect ground?

[Reza]

@AWI i tested several states. with 15cm(jumper) and 1meter(twisted) and 5meter(twisted) and 30meter(CAT6) wire.with some boudrate(all boudrate for all states wire). with 120ohm resistor first and end bus also use 1k resistor pull up and down D+ and D- :) so i tested all states of modules and wiring .i think this is related to trasport rs485 and same collision.best state was 15cm wire with 19200 boudrate.also 38400 worked but some errors

[Reza]

@AWI I have access to the necessary most modules and electronic components in my city . so if you have idea for this told me and i am ready to test .