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
uwe tazU

uwe taz

@uwe taz
About
Posts
3
Topics
2
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • understanding mysbootloader background to get working FOTA
    uwe tazU uwe taz

    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

    Troubleshooting

  • problems with RFM69_RFM95_ATC_SignalReport example
    uwe tazU uwe taz

    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.

    Troubleshooting

  • problems with RFM69_RFM95_ATC_SignalReport example
    uwe tazU uwe taz

    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
    
    Troubleshooting
  • Login

  • Don't have an account? Register

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