Navigation

    • Register
    • Login
    • OpenHardware.io
    • Categories
    • Recent
    • Tags
    • Popular
    1. Home
    2. NickBuilder
    3. Topics
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    Topics created by NickBuilder

    • NickBuilder

      Gibberish when serial.print() but MY_DEBUG look ok
      Troubleshooting • power pulsecount power meter pulse sensor volatile • • NickBuilder  

      7
      0
      Votes
      7
      Posts
      2168
      Views

      NickBuilder

      Thank you @scalz! That did the trick. Finally I can debug the code with readable serial feedback. Ok @AWI so the example code is probably in need for some adjustments. Its kinda hard for a beginner like myself to learn the basics if also the example code suffers from questionable functionality. Or perhaps the functionality is ok but the code by itself is not clear enough to educate the masses. I'm still having trouble understanding whats really happening when using the sleep() call. In my newest revision I'm not passing any interrupt conditions other than a time variable but still its obvious that the sleep is interrupted by the interrupt defined in the setup section. And as such, perhaps also some timer functionality is running while in a MySensors sleep. Perhaps the API description is in need for some additional clarification. Note: I've also deleted the attach and detach calls from the loop() section as this is probably handled by the sleep function (or other hidden code).
    • NickBuilder

      incomingMessage is not initiated on relay sensor
      Troubleshooting • • NickBuilder  

      7
      0
      Votes
      7
      Posts
      1936
      Views

      NickBuilder

      After migrating my few sketches to 2.0 and adjusting my baud rate to 38.4 kbps everything works! Thank you @scalz for pushing me to 2.0 and @ToniA for pointing out the poor choice of baud rate for the 8 Mhz Arduino. The recommended baud rate is now hard to miss in the 2.0 serial gateway example sketch. So moving to the latest API would possibly have solved my problems anyhow. // Define a lower baud rate for Arduino's running on 8 MHz (Arduino Pro Mini 3.3V & SenseBender) #if F_CPU == 8000000L #define MY_BAUD_RATE 38400 #endif Moving on to new challenges.
    • NickBuilder

      Need help understanding a parity check with XOR
      Development • 433mhz upm esic parity • • NickBuilder  

      4
      0
      Votes
      4
      Posts
      2855
      Views

      mfalkvidd

      @NickBuilder said: Thank you @mfalkvidd for the very educational description. I thought that the check could have been as you described but I felt that it was too crude and simple. This doesn't seem to be the most typical use of "exclusive or" but I guess it does the job. There are more advanced ways. This scheme will not detect two bit errors in the same group (even or odd) and it can only detect errors, not correct them. But without knowing the reasoning behind the design it is impossible to say if it was a bad choice or not. Is it common to only include part of the transmission packet in the parity check? I would have assumed that the nib (Nib4) should be part of the bit check and that the parity bits would then be set or not set so that the complete packet is confirmed. Yes, it is common to exclude things. What things depends on the use case. From what I understand, the exact same message is always sent three times. If the z-bits were included in the checksum, a new checksum would have to be calculated for each time the message is sent. That would probably have a negative effect on the communication speed and would add complexity to the solution without adding any real benefit. If the checksum bits themselves (C) were included in the checksum calculation they would affect the checksum so the checksum would change so the checksum would have to be calculated again which would cause the checksum to change so the checksum would have to be calculated again and so on.