Navigation

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

    uwe taz

    @uwe taz

    1
    Reputation
    3
    Posts
    1
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online

    uwe taz Follow

    Best posts made by uwe taz

    • RE: problems with RFM69_RFM95_ATC_SignalReport example

      Great, that was the right hint. Now I get values. Thanks!!!

      But should it included in the example code? I had a look in the development branch. There it was fixed. But in the development -3.0.0 branch not.

      posted in Troubleshooting
      uwe taz
      uwe taz

    Latest posts made by uwe taz

    • understanding mysbootloader background to get working FOTA

      Hello,

      I try to get running the nice FOTA feature (I love it to use on ESP32). I have a pro mini 8MHz 3.3V node with NRF24L01+. Sometimes I get an sucessful upload of a new sketch and sometimes it takes very long time (over 5min) or it takes long time until myscontroller finds the node. I have the feeling that there are some corners where I could or was turned in the false direction. It resulted in several long nights...

      I have 4 topics in mind to the problem:

      1. github repo
        Shall I use the the development branch for mysbootloader on github? I wanted to avoid compiling the bootloader and only use the ready hex-files because I'm shure that I trip in some pitfalls. I read somewhere that with development branch it is still possible to use serial upload and with main branch not.
        Gernerally I could live with main branch but there is only one hex-file and I do not know for which HW it is. And then there is a third branch UpdateBoardFiles. I did not understand for what it is.
      2. two 8MHz Versions
        I noticed that there are two 8MHz hex-Files and Entries. I took the NRFduino because the fuses are similar to normal pro mini. Is it the right one?
      3. fuses
        I noticed that in all 4 entries the extended_fuses=0x06. This is completely another value than in the "normal" pro mini bootloader. I had a look at the atmega328P data sheet and saw that only 3 lower bits are defined for brown out feature and these combination of the lower 3 bits is reserved. Is there any reason for that?
      4. time until sketch is started
        I wrote a simple blink sketch (with using millis for delay - my first pitfall) and later with deactivating watchdog (second pitfall). Now I wonder because of long (10s-1min) and various time until the sketch is started. I could isolate a little bit: If I cut the SCLK connection to to NRF it starts instantly. Without NRF and only powered with 2xAA cells too. Yes I understand that the bootloader has to check for a message from controller but why with a variable time although I have not a switched on/powered GW?
        As another cause I found the serial/USB connection. If I power the node via a TTL/USB Converter at an Windows USB port (to read serial outputs) it also takes long time to start. If I plug these vehicle to an USB powerbank it starts instantly too.
        Is these behave explainable?

      Many thanks for some helpfull hints in advance!
      Uwe

      posted in Troubleshooting
      uwe taz
      uwe taz
    • RE: problems with RFM69_RFM95_ATC_SignalReport example

      Great, that was the right hint. Now I get values. Thanks!!!

      But should it included in the example code? I had a look in the development branch. There it was fixed. But in the development -3.0.0 branch not.

      posted in Troubleshooting
      uwe taz
      uwe taz
    • problems with RFM69_RFM95_ATC_SignalReport example

      Hello,

      I'm running since some weeks a serial GW (based on Nano) and some nodes (based on pro mini) with RFM69HW. I use lib version 2.3.2 and tried to get running the RFM69_RFM95_ATC_SignalReport.ino example. I only changed in the sketch the definition to RFM69HW (refer git diff report at the end) and put the sketch to a node. At the GW I additionally added #define MY_RFM69_NEW_DRIVER. The communication is working.

      The problem is that all 6 return values of transportGetSignalReport are always zero.

      Has anybody a hint for me what I do not in the right way?

      Thanks for an answer in advance.
      Uwe

       // RFM69
      -//#define MY_RADIO_RFM69
      -//#define MY_RFM69_NEW_DRIVER   // ATC on RFM69 works only with the new driver (not compatible with old=default driver)-//#define MY_RFM69_ATC_TARGET_RSSI_DBM (-70)  // target RSSI -70dBm
      -//#define MY_RFM69_MAX_POWER_LEVEL_DBM (10)   // max. TX power 10dBm = 10mW
      +#define MY_RADIO_RFM69
      +#define MY_IS_RFM69HW //only for high power version
      +#define MY_RFM69_NEW_DRIVER   // ATC on RFM69 works only with the new driver (not compatible with old=default driver)
      +#define MY_RFM69_ATC_TARGET_RSSI_DBM (-70)  // target RSSI -70dBm
      +#define MY_RFM69_MAX_POWER_LEVEL_DBM (10)   // max. TX power 10dBm = 10mW
      
       // RFM95
      -#define MY_RADIO_RFM95
      -#define MY_RFM95_ATC_TARGET_RSSI_DBM (-70)  // target RSSI -70dBm
      -#define MY_RFM95_MAX_POWER_LEVEL_DBM (10)   // max. TX power 10dBm = 10mW
      +//#define MY_RADIO_RFM95
      +//#define MY_RFM95_ATC_TARGET_RSSI_DBM (-70)  // target RSSI -70dBm
      +//#define MY_RFM95_MAX_POWER_LEVEL_DBM (10)   // max. TX power 10dBm = 10mW
      
      posted in Troubleshooting
      uwe taz
      uwe taz