1. 21 Apr, 2016 1 commit
  2. 07 Apr, 2016 1 commit
  3. 05 Apr, 2016 1 commit
  4. 04 Apr, 2016 7 commits
  5. 02 Apr, 2016 1 commit
  6. 01 Apr, 2016 3 commits
  7. 28 Mar, 2016 1 commit
    • mz-fuzzy's avatar
      Linux library name backward compatibilty using simlink · ef1914b4
      mz-fuzzy authored
      Linux library name and symlinks adaptations
      Linux library version taken from library.properties (including python lib installation)
      ldconfig bugfixing
      Linux makefile cleanup
      Minor configure/makefile fixes
      ef1914b4
  8. 27 Mar, 2016 1 commit
  9. 26 Mar, 2016 2 commits
    • TMRh20's avatar
      RPi Interrupts w/SPIDEV Bugfix: Enable mutex lock · e69b1f86
      TMRh20 authored
      It seems mutex locking is still required when using SPIDEV. Errors only
      become apparent with very heavy radio traffic (HARDWARE FAIL: RADIO NOT
      RESPONDING )
      e69b1f86
    • mz-fuzzy's avatar
      makefile: 'configure' target added · 46824af3
      mz-fuzzy authored
      makefile: upload actions announce error when remote machine not set
      makefile: report destination directories when installing/uploading
      synchronizing makefiles for linux examples
      RF24_config.h - changed detection of makefile build
      minor configure/makefile improvements
      46824af3
  10. 25 Mar, 2016 1 commit
    • TMRh20's avatar
      RPi Bugfix: False Hardware Failure indication · 3e15a1ad
      TMRh20 authored
      Was finally able to successfully recreate conditions to consistently
      cause 'HARDWARE FAILURE RADIO NOT RESPONDING' messages on RPI master
      node:
      1: Using RPi B2.0 with Raspbian 4.1.20+ armv61
      2. Using 2 matching nrf24l01 non-PA modules w/ext antenna
      3. Using RF24Gateway + RF24Ethernet
      4. Using Arduino Due as RF24Ethernet node
      
      Test scenario: Mesh working normally for very long periods of time.
      Re-introduced an old node using Arduino Due. Immediately started
      noticing error msgs on master node.
      
      Solution: Increasing the wait time from 85 to 95ms seems to prevent
      false indications of hardware failures. It appears, the code was just
      not waiting long enough.
      3e15a1ad
  11. 24 Mar, 2016 6 commits
  12. 23 Mar, 2016 5 commits
  13. 20 Feb, 2016 5 commits
  14. 19 Feb, 2016 2 commits
  15. 14 Feb, 2016 2 commits
  16. 09 Feb, 2016 1 commit