Navigation

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

    kisse66

    @kisse66

    19
    Reputation
    29
    Posts
    493
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online

    kisse66 Follow

    Best posts made by kisse66

    • RE: OTA FW update using I2C EEPROM

      It seems to work now. Boot loader needs some more work, but MySensors part should be usable. If someone likes to have a look you can find it at http://github.com/kisse66/MySensors fork. By default it still uses SPI flash and works just like the original. To use I2C EEPROM uncomment (MyConfig.h) or define MY_OTA_USE_I2C_EEPROM in your sketch. You'll need also MY_OTA_FIRMWARE_FEATURE of course.
      My code uses Wire library for I2C (new driver) and defaults to address 0x50 (real I2C address 0xA0) that most EEPROMs use I think. EEPROM has to use 16-bit addresses, 24(L)C256 or 512 should work.
      Only tested with MYScontroller, pro mini 8MHz with nRF24 and 24LC512 EEPROM on AVR HW I2C.

      Do note that I'm still working on the bootloader part which you'll need to make this actually work. I have a "seems like working" hack, but it needs some more work. Approach is to use DualOptiboot code and add option there for alternate I2C. I'll publish it when it's getting a bit better.

      posted in Development
      kisse66
      kisse66
    • OTA FW update using I2C EEPROM

      Hi,

      I have boards with I2C EEPROM (32 or 64kB) instead of a SPI flash already supported via dualoptiboot. Been looking a bit but haven't found any discussion about such so far? Sorry if I have missed one.
      I have both nRF24 and RFM69 radios in use and going to mysensors from my earlier proprietary system.

      Anyway I already started implementing changes to dualoptiboot and mysensors OTA code. IF someone knows of existing work please do point me there so I can stop working on it. My idea is to make a simple EEPROM (24(L)Cxxx) driver that looks like the SPI flash driver to make the changes to mysensors minimal. Seems so far only a few lines are needed in addition to the new driver. Bootloader is a bit more work. Any comments about this approach (in case it starts working well and someone else likes to use it) ?

      posted in Development
      kisse66
      kisse66
    • RE: [SOLVED] Weird serial GW problem

      One more update:

      have not fully verified, but it seems like this was RF interference issue (maybe a transmitted ACK??).

      I added a 100n ceramic cap to power in line (at the GPIO connector) and 10nF caps from UART TX and RX to ground (small SMD caps at the connector). I also moved the antenna a bit higher by soldering coaxial cable to RFM and then peeling off the outer shield of the coax for the ~80mm. Problem gone!

      I'll add a ground plane to the antenna by putting aluminium tape to the top cover (missing here) and connecting the coax shield to it. Makes a better antenna and better shielding towards RPi. Have not re-checked range yet, but checked the UART signals with scope and the 10nF looks good as noise filter.

      0_1498848693734_WP_20170630_003 (2).jpg

      posted in Troubleshooting
      kisse66
      kisse66
    • RE: E73 nrf52 sleep current

      Hmm, should read the manual?

      ERRATA [89] TWI: Static 400 µA current while using GPIOTE

      after adding the workaround before sleep

      *(volatile uint32_t *)0x40004FFC = 0;
      *(volatile uint32_t *)0x40004FFC;
      *(volatile uint32_t *)0x40004FFC = 1;
      

      sleep current goes down to 29uA. It's a bit high still but usable with AA batteries!

      NRF_FICR->INFO.VARIANT tells my chip is version AAB0

      posted in Hardware
      kisse66
      kisse66
    • RE: OTA FW update using I2C EEPROM

      @Nca78
      Good question - Have only tested 256 and 512kbit (32/64kB), nothing bigger than 64kB. Unfortunately I2C protocol is slightly different between different EEPROMs, so code does have limitations. There's two sides of it. MySensors side now uses extEEPROM underneath, so what it supports should work. Address type is 32-bit, so the interface supports >64kB. Haven't checked the code, but at least it defines 2Mbit type (see extEEPROM.h). My patch now assumes EEPROM is 32kB (64 fine) as it's enough for mega328.

      Bigger issue is the bootloader, which has more assumptions. Likely not working as is for anything bigger than 64kB. Would be interesting to hear if someone can try, I don't have larger EEPROMs.

      posted in Development
      kisse66
      kisse66
    • RE: [SOLVED] Weird serial GW problem

      ok/FYI,
      seems there is nothing wrong with GW HW nor arduino code - I removed my GW module from RPi and used a USB serial to attach it to a windows PC running MYSController in GW mode instead. My nodejs controller connects to it rather than the local serial port and suddenly everything works, no more missing newlines. I even feed power only through FTDI cable and it still feels stable, even OTA completed fine.

      Before this I did try increasing Arduino serial TX_BUFFER to 128 bytes, but it had no visible effect.

      So it must be something in RPi serial port or nodejs serial interface. At this point I don't think its in my controller code (loosely based on the MySensorsSampleController), since I print the raw data from serial port first at the event handler and that already shows the missing data:

      }).on('data', function(rd) {
                                      logger.debug('gw' + i + " data: appending '" + rd + "'");
                                      appendRfData(rd.toString(), db, i);
      

      e.g. I saw

      [2017-06-14 12:23:06.975] [DEBUG] [default] - gw 2: appending '243;255;4;0;2;03'
      [2017-06-14 12:23:07.980] [DEBUG] [default] - gw 2: appending '243;255;'
      [2017-06-14 12:23:07.982] [DEBUG] [default] - gw 2: appending '4;0;2;03'
      [2017-06-14 12:23:07.984] [DEBUG] [default] - gw 2: appending '000200E7'
      [2017-06-14 12:23:07.986] [DEBUG] [default] - gw 2: appending '05
      '
      [2017-06-14 12:23:07.987] [DEBUG] [default] - rfm69 RX: 243;255;4;0;2;03243;255;4;0;2;03000200E705
      

      so one newline missing assembling two messages together.

      So problem kind of solved, at least there is no issue in MySensors side. It's been running now for 30 minutes, 3 ping-pong test msg per second and none lost.

      posted in Troubleshooting
      kisse66
      kisse66
    • RE: E73 nrf52 sleep current

      @omemanti

      yes, I noticed it uses 3mA after re-program. Seems to keep debug circuits on. After power on/off goes down

      posted in Hardware
      kisse66
      kisse66
    • RE: OTA FW update using I2C EEPROM

      @manutremo

      now merged, thanks!

      So this should fix the bootloader hang without pullups. The binary got a bit bigger again, but does not change much of anything since it still fits into 2k (1024W).
      I tested it with 8 and 16MHz pro mini with a few different EEPROMs (256 and 512kb).

      posted in Development
      kisse66
      kisse66
    • Battery based NRF52 sensor compile options?

      I have NRF52-based rain gauge. works well and got finally proper power consumption, but seem to have one problem to solve.
      It sends multiple sensor values and then goes to sleep for 20 minutes. This one is on the edge of radio coverage and occasionally seem to loose connection. Below is battery voltage measurement. You can see, that when there's a gap in the values (something wrong in radio coverage) the battery voltage drops rapidly, which suggests it does not sleep, but keeps trying something:

      0_1558718789617_2019-05-24 (2).png

      So the question is is there a good set of compile options to remove all checks etc, as I only want this one to send the values? If it fails just try again after the sleep period.

      Currently I have

      #define MY_SMART_SLEEP_WAIT_DURATION_MS  400
      #define MY_TRANSPORT_UPLINK_CHECK_DISABLED
      #define MY_TRANSPORT_WAIT_READY_MS  5000
      #define MY_RADIO_NRF5_ESB
      

      values are sent like

      send(msg);
      

      Any suggestions?

      posted in Troubleshooting
      kisse66
      kisse66
    • RE: E73 nrf52 sleep current

      @omemanti
      somehow missed that discussion...

      posted in Hardware
      kisse66
      kisse66

    Latest posts made by kisse66

    • RE: NRF52 watchdog problem (myBoardNRF5)

      @monte yes, makes sense. I know it takes quite a lot of energy to do one cycle due to multiple (slow) sensors and sending those, but have not really looked into a short wake, skip everything and back to sleep. Could easily count wakeups and only do the sensors every Nth wakeup. Maybe it's actually a good way.
      I have some weird issues for which I need the WDG. Found and fixed one forever loop in I2C, but it did not fix all. Can't pinpoint the issue and now it drains the battery randomly by getting stuck somewhere after a week or a few months.

      Now I remember one experiment over a year ago with NRF51 based small board I used as mysensors remote. It has just one push button. This silicon version had problem with high current draw if waiting for pin change, so I just made it wakeup every 750ms, poll the button and if not pressed go back to sleep. CR2032 lasted way over a year. Had already forgotten that, good that you reminded!

      posted in Troubleshooting
      kisse66
      kisse66
    • RE: NRF52 watchdog problem (myBoardNRF5)

      yep.

      So if the description is wrong you can't really use WDG with sleeping sensors, unless the sleep period is less than WDG period ?

      posted in Troubleshooting
      kisse66
      kisse66
    • RE: NRF52 watchdog problem (myBoardNRF5)

      @monte understood, however the MySensorsNRF5 says

      "*The MySensors port for nRF5 supports using the Watchdog. You can use the same commands like defined in "avr/wdt.h" but disable cannot disable the watchdog. The watchdog is set to a period of 36h of CPU runtime.

      When the CPU is in a sleep mode, the watchdog timer is stopped*."

      Especially the suspend, or better lack of, under sleep is my problem. I could set it for >20 minutes (sleep time) perhaps, but if the CPU hangs the long period will use a lot of battery before recovering.

      posted in Troubleshooting
      kisse66
      kisse66
    • NRF52 watchdog problem (myBoardNRF5)

      Have I missed something or is there an issue with watchdog on NRF52 - watchdog does not get suspended when sleeping ?

      Using mysensors 2.3.1 and NRF52832 (Ebyte module) with myboardNRF5. I finally took the time to simplify the code and seems you only need minimum sketch to replicate this, just sleep for longer than wdg period.

      Disabling it manually (wdg_disable) before entering sleep does not change this. I did read the disable is not working, but should set it for long period. Now testing with 20s sleep and 10s wdg period, reboots at every sleep after 10s.

      Ignore the TEST_PIN stuff, it's there to make it easier to re-program (STlink can't connect while sleeping).
      wait() seems to be calling wdg_reset since it doesn't boot there.

      #define MY_DEBUG
      #define MY_RADIO_NRF5_ESB
      #include <MySensors.h>
      
      #ifdef MY_DEBUG
      #define DBG_PRINT(...)    Serial.print(__VA_ARGS__)
      #define DBG_PRINTLN(...)    Serial.println(__VA_ARGS__)
      #else
      #define DBG_PRINT(...)    do {} while (0)
      #define DBG_PRINTLN(...)    do {} while (0)
      #endif
      
      
      #define REED_PIN	18
      #define TEST_PIN	29	// sleep -> wait
      
      
      
      void setup()
      {
      	hwPinMode(REED_PIN, INPUT_PULLUP);
      	hwPinMode(TEST_PIN, INPUT_PULLUP);
      	Serial.begin(115200);
      
      	DBG_PRINT("PART: ");
      	DBG_PRINTLN((uint32_t)NRF_FICR->INFO.PART, HEX);
      	DBG_PRINT("VARIANT: ");
      	DBG_PRINTLN((uint32_t)NRF_FICR->INFO.VARIANT, HEX);
      
      	wdt_enable(10000);
      }
      
      void loop()
      {
      	int8_t stat=0;
      
      	if (digitalRead(TEST_PIN)) {
      		DBG_PRINTLN("sleep");
      		//wdt_disable();
      
      		//int8_t stat = smartSleep(digitalPinToInterrupt(REED_PIN), FALLING, 20000);
      		//int8_t stat = sleep(digitalPinToInterrupt(REED_PIN), FALLING, 20000);
      		int8_t stat = sleep(20000);
      
      		//wdt_enable(10000);
      	}
      	else {
      		DBG_PRINTLN("wait");
      		wait(20000);
      	}
      
      	DBG_PRINT("Wakeup, stat ");
      	DBG_PRINTLN(stat);
      	wdt_reset();
      }
      
      posted in Troubleshooting
      kisse66
      kisse66
    • RE: Battery based NRF52 sensor compile options?

      I tried all the options and maybe got a bit better battery life. However I have now found out, that the actual problem is not likely radio connection after all, but I2C related problem. Started getting more of random drops and after adding some more debug stuff I finally found, that it sometimes get stuck in HTU21 driver, that had a forever loop if there was no proper response. The driver code has later been modified (Adafruit) to avoid this loop. I had my own async version of it, which had the same bug (same code, but split into start() and read() to avoid the delay saving run time).

      So likely this random dead battery issue was forever loop draining the battery. Have no idea why it sometimes rebooted by itself, recently it has just died and after reset (battery off and back on) the battery is more or less empty.

      posted in Troubleshooting
      kisse66
      kisse66
    • RE: Battery based NRF52 sensor compile options?

      @nagelc

      good point, have to try. Actually I now have one repeater, but can remove it or maybe move it even closer and use that as static.

      posted in Troubleshooting
      kisse66
      kisse66
    • Battery based NRF52 sensor compile options?

      I have NRF52-based rain gauge. works well and got finally proper power consumption, but seem to have one problem to solve.
      It sends multiple sensor values and then goes to sleep for 20 minutes. This one is on the edge of radio coverage and occasionally seem to loose connection. Below is battery voltage measurement. You can see, that when there's a gap in the values (something wrong in radio coverage) the battery voltage drops rapidly, which suggests it does not sleep, but keeps trying something:

      0_1558718789617_2019-05-24 (2).png

      So the question is is there a good set of compile options to remove all checks etc, as I only want this one to send the values? If it fails just try again after the sleep period.

      Currently I have

      #define MY_SMART_SLEEP_WAIT_DURATION_MS  400
      #define MY_TRANSPORT_UPLINK_CHECK_DISABLED
      #define MY_TRANSPORT_WAIT_READY_MS  5000
      #define MY_RADIO_NRF5_ESB
      

      values are sent like

      send(msg);
      

      Any suggestions?

      posted in Troubleshooting
      kisse66
      kisse66
    • RE: E73 nrf52 sleep current

      @nca78

      about 27uA (Rigol DM3085) @3.2V. It only drops 1-2uA if I disconnect the sensors (all wires towards HTU21,BMP085,VEML6075, BH1750) which is about what the datasheet for those say under shutdown. So most is taken by NRF52. There can be other peripherals that could be turned off still before sleep maybe. Now I only handle the I2C errata and then shut it off before sleep (wire.end), the rest is in mysensors code for sleep.
      Sleep current does not change if I don't enable the DCDC. Perhaps the active current does a bit but can't measure it accurately (too fast).

      Just estimated that using AA-batteries it should last over 2 years. It only wakes up every 20min and runs about 400ms to send 7 values. But still I'd like to get better.

      This is my rain gauge / multisensor under upgrade. It was earlier powered by mega328+NRF24. Worked fine about a year, but then something happened and it started taking 2mA while sleeping. Didn't see any visible reason why.

      posted in Hardware
      kisse66
      kisse66
    • RE: E73 nrf52 sleep current

      @omemanti
      somehow missed that discussion...

      posted in Hardware
      kisse66
      kisse66
    • RE: E73 nrf52 sleep current

      @omemanti

      yes, I noticed it uses 3mA after re-program. Seems to keep debug circuits on. After power on/off goes down

      posted in Hardware
      kisse66
      kisse66