Skip to content
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. My Project
  3. RS485 Stress test
  • Getting Started
  • Controller
  • Build
  • Hardware
  • Download/API
  • Forum
  • Store

RS485 Stress test

Scheduled Pinned Locked Moved My Project
34 Posts 9 Posters 13.3k Views 13 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K Offline
    K Offline
    kimot
    wrote on last edited by
    #21

    @pjr @hausinger

    Ok.
    New topic is here:

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

    1 Reply Last reply
    0
    • L Offline
      L Offline
      LeoDesigner
      wrote on last edited by
      #22

      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.

      N 1 Reply Last reply
      1
      • L 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.

        N Offline
        N Offline
        napo7
        Hardware Contributor
        wrote on last edited by
        #23

        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 !

        1 Reply Last reply
        0
        • P Offline
          P Offline
          pjr
          wrote on last edited by pjr
          #24

          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.

          L 1 Reply Last reply
          0
          • msmacsM Offline
            msmacsM Offline
            msmacs
            wrote on last edited by
            #25

            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

            1 Reply Last reply
            0
            • P 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.

              L Offline
              L Offline
              LeoDesigner
              wrote on last edited by
              #26

              @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).

              1 Reply Last reply
              1
              • P Offline
                P Offline
                pjr
                wrote on last edited by
                #27

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

                L 1 Reply Last reply
                0
                • P pjr

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

                  L Offline
                  L Offline
                  LeoDesigner
                  wrote on last edited by
                  #28

                  @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.

                  1 Reply Last reply
                  0
                  • K Offline
                    K Offline
                    kimot
                    wrote on last edited by
                    #29

                    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.

                    L 1 Reply Last reply
                    0
                    • K 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.

                      L Offline
                      L Offline
                      LeoDesigner
                      wrote on last edited by LeoDesigner
                      #30

                      @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.

                      1 Reply Last reply
                      0
                      • R Offline
                        R Offline
                        Reza
                        wrote on last edited by
                        #31

                        @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....

                        AWIA 1 Reply Last reply
                        0
                        • R 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....

                          AWIA Offline
                          AWIA Offline
                          AWI
                          Hero Member
                          wrote on last edited by
                          #32

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

                          R 2 Replies Last reply
                          0
                          • AWIA AWI

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

                            R Offline
                            R Offline
                            Reza
                            wrote on last edited by
                            #33

                            @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

                            1 Reply Last reply
                            0
                            • AWIA AWI

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

                              R Offline
                              R Offline
                              Reza
                              wrote on last edited by
                              #34

                              @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 .

                              1 Reply Last reply
                              0
                              Reply
                              • Reply as topic
                              Log in to reply
                              • Oldest to Newest
                              • Newest to Oldest
                              • Most Votes


                              4

                              Online

                              11.7k

                              Users

                              11.2k

                              Topics

                              113.0k

                              Posts


                              Copyright 2019 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
                              • Login

                              • Don't have an account? Register

                              • Login or register to search.
                              • First post
                                Last post
                              0
                              • OpenHardware.io
                              • Categories
                              • Recent
                              • Tags
                              • Popular