RS485 Stress test
-
Ok.
New topic is here:https://forum.mysensors.org/topic/5327/can-bus-transport-implementation-for-mys
-
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. -
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.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 !
-
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.
-
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
-
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.
@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
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. -
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. -
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.@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 3We need to ask someone to make minor changes to the MyTransportRS485.cpp or submit PR to the MyTransportRS485.cpp.
-
@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.... -
@Reza I think I had more than 5 meter in between, but I disassembled the circuit for now. Did you connect ground?
@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 I think I had more than 5 meter in between, but I disassembled the circuit for now. Did you connect ground?