Skip to content
  • MySensors
  • 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. Troubleshooting
  3. Read this first - it could SAVE YOU A LOT OF TIME

Read this first - it could SAVE YOU A LOT OF TIME

Scheduled Pinned Locked Moved Troubleshooting
17 Posts 12 Posters 25.9k Views 20 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.
  • pellusfromtellusP pellusfromtellus

    @sundberg84: Tks for answering! :)

    mfalkviddM Offline
    mfalkviddM Offline
    mfalkvidd
    Mod
    wrote on last edited by
    #8

    @pellusfromtellus thanks for noticing. I've updated the connect radio page, hopefully it is a bit clearer now.

    @sundberg84 nice profile picture. Great to get a face for you :)

    1 Reply Last reply
    1
    • N Offline
      N Offline
      Nicklas Starkel
      wrote on last edited by
      #9

      I just checked my sensors and I'm using 470µF.
      Shows to go you really should check what you grab from a bag of capacitors ;)

      1 Reply Last reply
      0
      • P Offline
        P Offline
        pjr
        wrote on last edited by
        #10
        "Error sending command, check device/hardware"
        

        I had oxidized dupont wires between radio and arduino. Good thing to check if your sensors lives outside!

        1 Reply Last reply
        2
        • mfalkviddM Offline
          mfalkviddM Offline
          mfalkvidd
          Mod
          wrote on last edited by
          #11

          I have updated the instructions above with references to the new awesome online log parser tool created by @hek. https://www.mysensors.org/build/parser

          1 Reply Last reply
          2
          • sundberg84S sundberg84

            @pellusfromtellus - its a typo... mostly I use a 4.7uF but to be honest im not sure which is the "recommended".

            Bogus ExceptionB Offline
            Bogus ExceptionB Offline
            Bogus Exception
            wrote on last edited by
            #12

            This is old, but I was looking through it today...
            According to the datasheets for voltage regulators and the reports of why there are problems with the nRF, the output, or load side capacitors are for keeping the voltage into the nRF as steady as possible. smaller caps are on the front side of the regulators for noise (faster transient voltages than what you'd see on the nRF draw), like those from other electronics, certain lights, radios, etc. and they are ceramic (or other non-polarized) that are great for this filtering in a small package.
            The regulators themselves, like the ones in the Arduinos (if you feed RAW pin) take care of the high frequency stuff, but a bigger capacitor is needed for voltage variations, which a ceramic can't do. This is why electrolytics are used. The problem is, electrolytics are much bigger, and so most regulators have you add them to make them work better. But where would you put a component larger than the MCU's chip? And besides, they are getting smaller all the time.
            I've never seen anyone say what value cap is overkill, as each person's setup is different. Some don't power their radios from the MCU's rail at all, and some MCUs can be loaded with servos, etc. that would make their draw on transmit different than yours. The bigger the cap (as long as voltage is a tad over what it will see) the better, when it comes to electrolytics. In fact, you can power your MCU with them!
            The only way you can know what will work in your unique situation is with an oscilloscope. It is fast enough to capture any dips in voltage on transmit/power-up, and it can show you any noise and ripple on the input. VOMs are just too slow, and not made to measure small changes in a higher voltage at the speeds you will need to see them.
            Since I have a pile of 10uf and 100uf, I start with 10uf by default, and if there is any errors that seem like TX dropout, I'll try 100uf, but a cap in this scenario is only a bandaid making up for an under-powered board, IMHO. With battery size/count restrictions, we don't have any choice, but in AC powered systems we should have a PS beefy enough to allow the radio and all peripherals to go nuts without affecting each other.
            If you suspect a supply voltage dropout to the nRF, you'll receive fine. So maybe try taking the other peripherals out one by one, maybe measuring overall current draw, and see if the symptom at some point goes away.
            And finally, my opinion is that the radio board is the most suspect piece in the chain. Playing musical parts might save you messing with the caps... :)

            "If you drop it and it breaks, it was good." ~ Mr. Lehr, my Electronics Vo-Tech teacher, on testing vacuum tubes...
            -Arduinos (UNO, Nano, Pro-Mini, Mega, ...)
            -ATTiny, ATMega, STM32
            -Geek Channel: https://www.youtube.com/TheSalesEngineer

            1 Reply Last reply
            2
            • alowhumA Offline
              alowhumA Offline
              alowhum
              Plugin Developer
              wrote on last edited by
              #13

              Now that encryption is becoming more common, perhaps there can be some tips/flowchart on how to troubleshoot that?

              For example, I just discovered that clearing the eeprom (there is a special sketch for that in the examples folder) helps remove old encryption settings.

              AnticimexA 1 Reply Last reply
              0
              • alowhumA alowhum

                Now that encryption is becoming more common, perhaps there can be some tips/flowchart on how to troubleshoot that?

                For example, I just discovered that clearing the eeprom (there is a special sketch for that in the examples folder) helps remove old encryption settings.

                AnticimexA Offline
                AnticimexA Offline
                Anticimex
                Contest Winner
                wrote on last edited by
                #14

                @alowhum the security documentation is quite clear on the use of eeprom for encryption keys.

                Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)

                1 Reply Last reply
                0
                • TRS-80T Offline
                  TRS-80T Offline
                  TRS-80
                  wrote on last edited by
                  #15

                  Like many, I struggled for literally years getting MySensors to work. Recently I tried (yet again) and this time around I began by focussing on an evidence based radio testing method, which for me was the key to success. I humbly cross-link it from here in the hopes that it is helpful to others, because it makes me sad reading how many people have given up trying to get MySensors to work.

                  Good luck!

                  And by all means please do not suffer, struggling along in silence. Make a post and try and get some help before frustration mounts too high, and you give up (as I did, many times).

                  1 Reply Last reply
                  2
                  • mfalkviddM mfalkvidd

                    Troubleshoot the debug output

                    (courtesy of @martinhjelmare from this thread)

                    From the source code in the dev branch: link

                    s = sensor id
                    c = message type 0-4: presentation, set, req, internal or stream. See link
                    t = value type: S_VALUE during presentation or V_VALUE during set/req
                    pt = payload type: string, byte int, etc. See link
                    l = message length
                    sg = signed or unsigned message: 0 or 1 for false or true

                    0;0;3;0;9 means node 0 , sensor 0, internal message (3), not an ack message (0), log message (9). This means that it's the gateway that prints this info as a log after already having received the message from a node.

                    At the end you have the payload: 27

                    Similarly for a sent message: link

                    C Offline
                    C Offline
                    ctodor
                    wrote on last edited by
                    #16

                    @mfalkvidd what if we replace "s" with "sensorId" and so one?

                    mfalkviddM 1 Reply Last reply
                    0
                    • C ctodor

                      @mfalkvidd what if we replace "s" with "sensorId" and so one?

                      mfalkviddM Offline
                      mfalkviddM Offline
                      mfalkvidd
                      Mod
                      wrote on last edited by
                      #17

                      @ctodor sorry, I don’t understand. Could you describe where the sensorid could be added?

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


                      18

                      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
                      • MySensors
                      • OpenHardware.io
                      • Categories
                      • Recent
                      • Tags
                      • Popular