Navigation

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

    Posts made by d00616

    • RE: nRF5 OTA updates

      @lorenzo said in nRF5 OTA updates:

      Hi, Any news on that? If needed I can help developping.

      No news from my side. Currently I have no time to work on this feature.

      You can fork my Repository https://github.com/d00616/ArduinoHwNRF5 to finish the work. It's possible to send a new firmware and the image is new replaced by the bootloader but with the first interrupt the MCU is crashing. For NF52 MCUs, I think this problem is fixable by moving the IV-Pointer to the image maybe there is an problem by different memory layouts of Arduino and Zephyr (used to compile mcuboot).

      posted in Development
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @neverdie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      @d00616 I guess this is what you mean by Zephyr? http://docs.zephyrproject.org/boards/arm/nrf52840_pca10059/doc/nrf52840_pca10059.html?highlight=nrf52840

      With Zephyr, I mean the Zephyr OS. This board definition is part of a newer Zephyr Version, I had used to compile mcuboot. This was ~7 Month ago.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      If someone try to work on mcuboot compatibility. Maybe only the IV is the problem. For NRF52 the IV can be moved to the beginning of the image, but the nRF51 IV is in the mcuboot rage.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      Sorry wrong wording. All P0 ports can be mapped. But to map P1 ports there is additional code required which does'n exists in the Arduino port.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @neverdie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      @d00616 Will everything work the same on the nRF52840?
      Has anyone tried it?

      Yes. At the moment, I have no time to finish my work on supporting the nrf52840. In my Repository https://github.com/d00616/ArduinoHwNRF5 you can find my last state. All 840 ports P0 (0-31) and P1 (62-64) should be usable as GPIO but there is no support using the P1 ports with any pin mapping component like UART, I2C....

      The second change in my last commit is mcuboot. A bootloader compiled with Zephyr. Firmware can be upgraded OTA using MYSController with some enhancements (ask @tekka about the correct version). Firmware transmision works well but, at the moment my mcuboot port don't work. The memory layout between zephyr and arduino is different. The application cashes after start. I think it's a problem with different memory layout between Arduino and Zephyr.

      For NRF52 MCUs the memory problem can be solved by moving the interrupt vector register to the IV location in the image and setting the SP register to the correct value. Maybe the starting code of ArduinoHwNRF5 is the correct position, so this mcuboot version can be used for Arduino and Zephyr Software.

      If moving the SP to the correct position doesn't help, for NRF51 the Arduino linker scripts must be changed. I think there is only a small change required, but I have no idea about how to do this.

      It's welcome if someone can finish this work.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: nRF5 OTA updates

      @andrew said in nRF5 OTA updates:

      I just started to review the NRF5* possibilities. regarding to the code protection, are you sure that you have to implement this by your own?
      what do you think about CTRL-AP - Control Access Port, APPROTECT?

      This is already implemented -> https://github.com/mysensors/MySensors/blob/development/hal/architecture/NRF5/MyHwNRF5.cpp#L69

      Do not enable this feature until the bootloader is working. I have an NRF52 board, I can't erase after enabling the feature. I think the problem is I haven't enabled the reset pin.

      I have tried to erase the MCU with ST-Link an CMSIS adapters. Maybe I have more luck with an J-Link.

      posted in Development
      d00616
      d00616
    • RE: nRF5 OTA updates

      @alowhum said in nRF5 OTA updates:

      Any luck? Has OTA support for NRF5 materialised?

      It's not complete yet. My idea is to use mcuboot as bootloader and the MySensors OTA protocol to transfer a new firmware image. The last one is completely finished. I use the zehpyr port of mcuboot. This is working fine for NRF52 MCUs, but it depends on an memory layout of zephyr. The arduino-nrf5 port is using another memory layout.

      At the moment, I can flash a new firmware image over the air, the image starts until the first interrupt routine is called. I think this can be fixed for NRF52 MCUs. Last time, I have looked into the mcuboot project, the NRF51 MCU wasn't supported.

      I can't work on that in the moment, because I'm very busy with non MySensors related tasks.

      posted in Development
      d00616
      d00616
    • RE: nRF5 action!

      @neverdie said in nRF5 Bluetooth action!:

      Speaking of batteries, I found only one proper holder for holding two CR2032's in series:

      There are CR2477 (560mAh) or CR2450 (950mAh) 3V cells. Maybe its's better to handle.

      posted in My Project
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @nca78 said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      Should we worry about that ?

      No. There are some ports of Arduino for NRF5. At the moment MySensors is not compatible with the Primo Port, because it comes with the SoftDevice. It changes nothing for the current state.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @monte said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      @d00616 thanks for a reply. I will evaluate my skills for this task, when I actually will get a chip to try it on. I need some really small pcb for my project, and single chip with mcu and rf with the size of nrf51 fits perfectly, but it requires quiet simple communications and full MySensors library will be overkill and hard to adapt for my needs.

      If possible use the nRF52 series. There are some improvements like better radio sensivity, lower current consumption, more RAM and flash, better ADC and a better CPU. Maybe in the future there is a Firmware update OTA functionality which is easier to adapt to the NRF52 than the NRF51 platform. Another reason to use the NRF52 is, that the official Arduino NRF5 port only supports the NRF52. This port has a lot more capabilities than the arduino-nrf5 port, but MySensors is not compatible at the moment.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @monte Thank you.

      @monte said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      @d00616 one more question. Is your driver able to send broadcast messages, without defined address, or should I just use the same node address on multiple receiving nodes?

      The broad cast address is hard coded to 0xff (255). Each node must have a uniqe address, because it's not possible to send packages to a node with the same address.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @monte said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      @d00616 thanks for a reply. I will evaluate my skills for this task, when I actually will get a chip to try it on. I need some really small pcb for my project, and single chip with mcu and rf with the size of nrf51 fits perfectly, but it requires quiet simple communications and full MySensors library will be overkill and hard to adapt for my needs.

      You can use the MY_CORE_ONLY mode -> https://forum.mysensors.org/post/76627

      posted in OpenHardware.io
      d00616
      d00616
    • RE: nRF5 action!

      @nca78 said in nRF5 Bluetooth action!:

      @neverdie I suppose the radio is using the high frequency clock, so it doesn't have any influence ?

      The LFCLK is required for BLE timing. Without the MCU required more energy to generate (synthetic) or calibrate (RC) the 32kHz signal.

      posted in My Project
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @monte said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      Hello, @d00616. Could you tell me which ESB library did you use to port it to arduino environment? The one that comes with Nordic SDK? After searching for few hours I haven't find any other realization of ESB mode for arduino IDE except your port included with MySensors. It's a pity. Are you going to release general purpose library, maybe?

      The ESB library is written from scratch. At the time of of starting the Nordic SDK license was incompatible with open source projects. I have no plans to release this as stand-alone library. At the moment there is only an subset of the ESB protocol implemented. Enough to be compatible with MySensors RF24 devices.

      Feel free to use my code to create a stand-alone library. If required, we can talk about dual licensing to code with an additional open source license.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: How to make radio ESB disable

      @icmathad said in How to make radio ESB disable:

      how to make radio ESB mode disable in MySensor API. please help me out.

      You can add a second NRF5 MCU or an dedicated BLE chip one for BLE and one for ESB.

      posted in General Discussion
      d00616
      d00616
    • RE: How to make radio ESB disable

      @icmathad said in How to make radio ESB disable:

      how to make radio ESB mode disable in MySensor API. please help me out.

      If you mean to switch between BLE and ESB. This is not possible at the moment.

      The function call to disable the SoftDevice is not available with the arduino-nrf5 port. This is required to release the radio interrupt. This function call is available with the Arduino Primo port.

      If you are using the NRF51 the used RTC for sleep() is conflicting with the SoftDevice. The SoftDevice must be disabled before sleep(). The NRF52 comes with an additional RTC, which is used for sleep().

      The most blocking reason the SoftDevice is unsupported is the arduino-NVM library, required as EEPROM emulation. This library isn't using the SoftDevice API for flash access. The library blocks the program flow, if a SoftDevice is present. I had invested some time without luck. I don't know why.

      Pull requests are welcome.

      posted in General Discussion
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @neverdie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      Ashes on my head. The mysensors code is working with I2c after all. I confirmed it on the second (alternate) node. I had switched two of the wires in the myboardnrf5 pinout, but hadn't on the generic nRF51 pinout. Correcting for that, it now works.

      Thank you for reporting this. Great news to hear this.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @neverdie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      @d00616 said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      I have I2C and serial running with a NRF52832.

      Yes, it does seem to work on the nRF52832. Just not presently on the nRF51822.

      Can you check, if the device works with the "Generic NRF51822" board? You can edit the variant files in the arduino-nrf5\variants directory.
      C:\Users...\AppData\Local\Arduino15\packages\sandeepmistry\hardware\nRF5\0.4.0\variants\Generic

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @neverdie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      @d00616 You mentioned that it works only with a particular version of GCC. Does that mean I need to have a particular version of the Arduino IDE installed? I'm currently running the latest version of Windows Arduino IDE, which is 1.8.5.

      The GCC version is part of the arduino-nrf5 distribution.

      @neverdie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      Unfortunately, it does not appear that I2C is working.

      I have I2C and serial running with a NRF52832.
      You can try to remove the compat_pin_mapping line and add the 0.1.0 pin map at this place. Then the board definition is nearly the 0.1.0 version.

      @neverdie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      However, it doesn't seem to be working on the nrf51.

      I check the NRF51 board. What do you mean with no working?

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @neverdie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      I think I made the changes you recommended, but now I'm getting:
      Board MyBoard_nRF51822 (platform nRF5, package MySensors) is unknown

      Error compiling for board MyBoardNRF5 nRF51822.

      I had the same message. In my case, I have uninstalled arduino-nrf5, cleared files, which are not removed from packages directory (the 0.2.1 MyBoard files) and reinstalled arduino-nrf5. After restarting Arduino it was fine.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @d00616 said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      I have changed the templates a little bit and moved the code for pin mapping generation. Now it works for me. Please give me some time to clear the code and create a new package (0.3.0). With the new package, you have to add '#include <compat_pin_mapping.h>' before '#end" in MyBoardNRF5.cpp. You have to rename the '#ifdefs' and '#define' in both board files to match MYBOARDNRF5 instead of MYNRF5BOARD.

      Now, there is a new Version 0.3.0 for MyBoardNRF5 available. It can be installed via the Board Manager. Please change the templates like described above. I think, now the board definition is stable and ready to support other Arduino variants without changing the board definition.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @d00616 said in ๐Ÿ’ฌ MySensors NRF5 Platform:
      Back from the compiler hell. There is no chance getting the GCC 4.8 to work without forking the arduino-nrf5 code. Compiling with GCC 4.8 has the same result.

      I have changed the templates a little bit and moved the code for pin mapping generation. Now it works for me. Please give me some time to clear the code and create a new package (0.3.0). With the new package, you have to add '#include <compat_pin_mapping.h>' before '#end" in MyBoardNRF5.cpp. You have to rename the '#ifdefs' and '#define' in both board files to match MYBOARDNRF5 instead of MYNRF5BOARD.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @rmtucker said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      Where is myBoardNrf5 so i can check?

      This is the better repository: https://github.com/mysensors/ArduinoHwNRF5

      @neverdie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      @d00616 Maybe you can just make it like it was before, where there was only one pair of I2c pins, not two as in your upgraded version? Maybe then it would work again.

      Please give me some time. After an debug session with @scalz and @Yveaux, I think this is a tool chain (GCC 5.3) problem. The pin mapping array is part of the binary, but the Wire constructor gets an array with 0 while the Wire instance has pin mapping information.

      Yesterday, I had a try to port ArduinoHwNRF5 back to the same tool chain (GCC 4.8) used by Arduino Primo and SAMD boards. I think for compatibility, this is the best option.

      If I have no luck, I either remove the option of the pin remapping table or I go back to the old version. I think going back is no good idea, because the NRF52840 has more than one 32 GPIO, which requires advanced parameters.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @NeverDie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      So, it would appear that there's something about the mysensors code that is causing the problems. @d00616 Can we please get it fixed?

      I have no I2C Hardware for testing, but I take a look into the I2C and MySensors code soon.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: nRF5 action!

      @Toyman said in nRF5 Bluetooth action!:

      @d00616 everything is working EXCEPT relay control.
      So the node is recognized in Domoticz, I can switch it on and off, but the relay just doesn't switch on permanently when I send HIGH to the pin. It switches on and almost immediately off.

      With the extended output mode, you are on the safe side, but I think this isn't the problem. Maybe domoticz sends the off command or there is something in the sketch logic. Please try to switch on the port outside the MySensors logic like in setup() or by the button.

      Your design has connected a button to P0.00 and an transistor to P0.01. These pins are for the 32kHz clock. Please check, that you have to choosen the RC oscillator as LFCKL source.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @Toyman said in nRF5 Bluetooth action!:

      The schematic is given. I just don't understand why it worked with BLE core and why it doesn't with d0016's.
      I always thought Mysensors is an extension of vanilla nrf5 arduino core.

      You have to remove the SoftDevice. The EEPROM Emulation, included in MySensors, is incompatible and the radio and RTC interrupt is blocked by the SoftDevice. The system call to disable the SoftDevice is not available in the Arduino port. Here is some example to erase the MCU.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Not in the current test code that I'm running.

      Interesting. The SPI is rated with <1ยตA idle current. TWI has no idle current in the datasheet.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Well, it could be within the bounds of measurement error, but it appears that dropping I2c and SPI has reduced the drain to 2.6ua.

      Is I2C or SPI used somewhere in your code?

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @ahmedadelhosni said in nRF5 Bluetooth action!:

      Is signing soft supported or not yet ?
      The personalizer sketch do not have hash define for the NRF52.

      The security personalizer is working with the NRF5X. Random numbers for the Soft Signing are generated with the internal AES hardware, seeded with the hardware number generator. This allows a fast and secure nonce generation.

      At the Moment the NRF5 with Soft Signing is not at the same level like the ATSHA204, because the read back protection is not enabled. If you want to do this, you have to add some code.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @Jokgi said in nRF5 Bluetooth action!:

      @NeverDie check out a product called "TAG-CONNECT". It is perfect for programming. It is used on the Nordic Semiconductor Beacon Reference Design.

      Thank you. Here is an programmer with this connector: http://aconno.de/acnprog/
      I don't know if this is compatible to the Beacon Reference Design, but its compatible with the nRF52 boards provided by aconno.

      posted in My Project
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @NeverDie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      In any case, I'm sure the question will ultimately turn from "How do I wake up based on a pin change?" to "How do I wake up based on the LPCOMP output, which has that pin as its input?" The reason: as covered earlier in this thread, much lower current consumption while sleeping if doing it via LPCOMP rather than the more straightforward pin monitoring.

      It's a good question about, how to design the API to do this. I have no good idea.
      Until an API, you can set MY_HW_RTC->CC[0] to (MY_HW_RTC->COUNTER+2). This ends sleep with some latency.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @NeverDie I have checked the sleep routine in all three variants. It's working with my setup.

      There is no API stopping the sleep() by another ISR. Sleep only ends at one of the given conditions.

      When you use the MY_CORE_ONLY define, please add "hwInit();" into the setup() routine.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @NeverDie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      BTW, I'm using the Windows version of Arduino IDE 1.8.5, which is the most current.

      I don't know the correct path on an Windows system. On my system the Sketches are in the ~/Arduino folder in my home directory (~). The arduino-nrf5 is in ~/.arduino15/packages/sandeepmistry/hardware/nRF5/0.4.0 and the ArduinoHwNRF5 files are in ~/.arduino15/packages/MySensors/hardware/nRF5/0.2.1

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @d00616 said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      @NeverDie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      I refreshed all the libraries. I'm able to compile and upload my sketches, but now it complains a lot about "invalid libraries."

      At the moment, I cannot reproduce this with Linux and Arduino 1.8.2. I try to find out what's wrong.

      Can you try to remove the .ci and .mystools folders?

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform

      @NeverDie said in ๐Ÿ’ฌ MySensors NRF5 Platform:

      I refreshed all the libraries. I'm able to compile and upload my sketches, but now it complains a lot about "invalid libraries."

      At the moment, I cannot reproduce this with Linux and Arduino 1.8.2. I try to find out what's wrong.

      posted in OpenHardware.io
      d00616
      d00616
    • RE: ๐Ÿ’ฌ MySensors NRF5 Platform
      1. I have updated the radio driver with fixes for some hardware errata.
      2. I have updated the https://github.com/mysensors/ArduinoHwNRF5 with an enhanced definition format. File name and contents are changed! The board description is compatible with the NRF5 variant provided by Arduino, but it's not possible to use this variant at the moment.
      posted in OpenHardware.io
      d00616
      d00616
    • RE: nRF5 action!

      @Toyman said in nRF5 Bluetooth action!:

      @d00616 have you looked at https://mynewt.apache.org/

      Yes, I have seen the documentation and some parts of the source code. It's a good project. I like the concepts.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Anyone tried building a bluetooth stack on the nRF5x from within the Arduino IDE? I can see how running it simultaneously with the mySensors code would be tricky, but maybe one could switch back and forth between the two? e.g. if you want to output debug text to a terminal window on your smart phone via bluetooth If so, anyone have any demo code for doing that?

      The parts of the SDK to disable and enable the SoftDevice are not included into the arduino-nrf5 port, but on the Primo port.

      For that matter, has anyone here tried the Arduino Primo? And if so, how did it go?

      The Arduino-NVM library is not compatible. This results in a crash. My first try to use the SoftDevice API was not successful.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @ahmedadelhosni said in nRF5 Bluetooth action!:

      Yes I read this from the datasheet but I thought maybe MySensors defines some Pins for debugging.
      How can I set them ? Any ApI refrences ?

      Most NRF5 pins are freely configurable. MySensors only uses the definition of the Arduino variant. If you are not lucky with the pins defined with the Arduino board variants, you can use the ArduinoHwNRF5 board. There are examples to redefine pins.

      This repository has the release 0.1.0 its usable and stable, but I have plans to rename the files to MyBoardNRF5 and change the g_ADigitalPinMap to the more flexible Arduino primo format in the near future. I think this is required to support NRF52840 MCUs in the future.

      posted in My Project
      d00616
      d00616
    • RE: Where to get legit nRF24L01+ modules?

      Sorry for my NRF24 clone post yesterday. The ACK bit was an issue with the NRF5 platform. I had switched the memory region to handle TX/RX/ACK packages separately. Sometimes the received packages are written in the wrong region. I had seen my testing ACK bit. Now, I have changed my NRF5 code and I can't see no difference between the modules, I have. ACK and timing are exactly at the same level.

      posted in Hardware
      d00616
      d00616
    • RE: nRF5 Multi Sensor Board (12-14โ‚ฌ)

      @Ptibu said in nRF5 Multi Sensor Board (12-14โ‚ฌ):

      I don't know how the sleep is implemented (CONFIG/GPIOTE) and if I'm facing this bug, but my battery lasts 2 days, with a wake-up period of 2 minutes (QFAAH0 MCU)... any idea?

      Do you have powered off the MCU after flashing? After programming, the debug interface is active. To disable this interface, you have to reset the MCU.

      posted in Hardware
      d00616
      d00616
    • RE: Where to get legit nRF24L01+ modules?

      @NeverDie said in Where to get legit nRF24L01+ modules?:

      @d00616 said in Where to get legit nRF24L01+ modules?:

      a node requires an hard reset from time to time.

      First I've heard of this. How often is "from time to time"?

      <0,1% of packages. I have three versions of the ESB protocol code. With the published version, the module hangs when PAN#102 is triggered. My second version was a try to fix this issue by adding some timer code. With this fix, the NRF5 looses more packages than before. The version I currently working on looks more stable, is easier to debug, supports the fast ramp up mode partially, but it's not complete yet.

      posted in Hardware
      d00616
      d00616
    • RE: Where to get legit nRF24L01+ modules?

      @NeverDie said in Where to get legit nRF24L01+ modules?:

      There's no reason to continue using nRF24L01's anyway, except for legacy situations.

      ...when https://github.com/mysensors/MySensors/issues/949 is fixed. If not, a node requires an hard reset from time to time.

      posted in Hardware
      d00616
      d00616
    • RE: Where to get legit nRF24L01+ modules?

      @gohan said in Where to get legit nRF24L01+ modules?:

      how did you setup NRF5 "sniffer" ?

      At the moment, I reimplement the protocol for NRF5 chips to fix an NRF5 hardware issue. I don't have a "sniffer".

      BTW, my red modules are working really great; the link you provided from aliexpress are really genuine?

      My red modules are good working clones, but they are clones which violating the protocol. Using clones resulting in sending more packages over the air and never receiving an ACK package from original NRF24. So it looks like a duck, but not quacks like a duck over the air.

      EDIT: Sorry, Cannot identify clones at the moment.

      posted in Hardware
      d00616
      d00616
    • RE: Where to get legit nRF24L01+ modules?

      @Nca78 said in Where to get legit nRF24L01+ modules?:

      @d00616 said in Where to get legit nRF24L01+ modules?:

      Some news. After playing with NRF5 and the NRF24 protocol. The red EBYTE modules are fakes.

      You mean you bought those red modules from Ebyte shop and they sent you some with a dot on the chip ?

      Yes. I had ordered the module in the form factor like this posted above.

      @gohan said in Where to get legit nRF24L01+ modules?:

      @d00616 Are you sure about that?

      Yes, about the ACK/NoACK handling. With the NRF5, I see raw packages. I'm not sure about the dot vs. rectangle, but my modules with a dot violating the protocol.

      posted in Hardware
      d00616
      d00616
    • RE: Where to get legit nRF24L01+ modules?

      Some news. After playing with NRF5 and the NRF24 protocol. The red EBYTE modules are fakes.

      Over the N of NRF is a dot. I have ordered these modules: https://aliexpress.com/item/Wireless-Module-NRF24L01-original-2-4-Ghz-RF-transceiver-SPI/32712174920.html they have an rectangle over the N and responding line an original NRF24L01. Maybe this helps to identify originals.

      The difference between both modules is in NoACK attribute handling. Fakes always responding with ACK and sending inverse NoACK attributes. So fakes have problems communicate with original modules.

      EDIT: This was an issue at the NRF5 side.

      posted in Hardware
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      @d00616 Also, at least so far, I haven't been able to get the Fanstel modules to receive anything. At first I thought it must be an LNA thing, but I tried it just now on a Fanstel module without LNA, and although it can transmit and blink just fine, the regular receive code isn't working. Any theories on that?

      I think this could be the memory layout -> linker script. My try to port Arduino to nrf51 in 2014 is failed at the same state. Blink was ok. Using something with memory are failed. The reason was a wrong linker script. At this time Nordic hasen't released (L)GPG compatible scripts.

      Edit: I think it's possible to add the 82810 to https://github.com/mysensors/ArduinoHwNRF5 by changing the board definition and add the missing linker script into the variant folder.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      I think we can rule out #3. So, if it isn't #2, then is perhaps #1 a factor? I wouldn't think so.

      I think, you have to do more things:

      1. Change compiler attributes to disable FPU support
      2. Change the memory layout in linker scripts. Look into boards definition. Linker scripts are placed under ./cores/nRF5/SDK/components/toolchain/gcc/ The SDK14 has scripts supporting the nrf52810
      3. The SDK14 has an dedicated startup code (gcc_startup_nrf52810.S), I don't know if this relevant for arduino-nrf5

      I think there is more to do than compile the code. I think the SDK code for arduino-nrf5 must be updated to SDK 14, then a nre MCU must be defined.

      I have compared the startup code. The difference is in the interrupt vector. It should work with the NRF52832 startup code, but the linker script must be changed.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 Multi Sensor Board (12-14โ‚ฌ)

      @ben999 said in nRF5 Multi Sensor Board (12-14โ‚ฌ):

      Could it be a direct replacement of Arduino Pro Mini and nRF24L01+ ?

      Maybe, the NRF5 can replace the combination of ATMEGA+NRF24 chips but it's a 3.3V chip and I don't know an NRF5 board in Arduino Pro Mini layout.

      Please look at https://forum.mysensors.org/topic/6961/nrf5-bluetooth-action/1092 for pros and cons.

      At the moment the radio protocol is a little bit unstable, because there is an hardware issue, which must be fixed in software. At the moment I do a rewrite of the ESB protocol, which fix this issue. My old implementation is hard to debug. With my new implementation the radio states are separated into extra functions and I use more of the nice event driven capabilities (PPI, Shorts). Until I have finished this fix, sometimes an NRF52 needs an reset.

      posted in Hardware
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      @d00616 Any thoughts or comments regarding this?

      Sorry, I can't help here. Maybe, the interrupt priority can be used only once and you have to use another priority for RTC or LPCOMP.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      @d00616 Is it still the case that we're limited to a single interrupt? For instance, I'd like to put the nRF52832 to wake-up periodically as a heartbeat where it reports its battery level, and I also want it to wake-up if a particular pin goes HIGH (e.g. if a PIR sensor is triggered). Presently I'm using the RTC to provide the one interrupt, and I use the PPI to create an RTC interrupt if it detects that the PIR sensor pin has gone HIGH. Then the interrupt code must determine the true cause of the interrupt. It would be cleaner if I could separate them into separate interrupts.

      You can wake up the MCU via:

      • GPIO pin sense; used for sleep()
      • GPIOTE; consumes less engergy but pin must be dedected in software (0.1ยตA-0.5ยตA)
      • LPCOMP (0.5ยตA)
      • QDEC (5ยตA)

      The interrupts for LPCOMP and QDEC are not allocated by the arduino-port. I think the LPCOMP is a good point to start with.

      posted in My Project
      d00616
      d00616
    • RE: Disconnecting client from gateway

      There are two reasons missing SoftDevice support. The License at the time of starting my port of MySensors to NRF5 and I don't like to have the SoftDevice on my Nodes. I have never tested MySensors with a SoftDevice present.

      At the moment I reimplement the ESB protocol, because there is an bug in the NRF52 hardware (PAN102) which I had no luck fixing it in the current ESB implementation. The new version uses more resources like PPI and Timer and splits the code for TX, TX with ACK and RX. I hope this is better to debug and easier to understand.

      When I find some time, I do some tests if this code works with a SoftDevice present. When it works, then I remove or change the error/warning message about SoftDevice support. I have no plans to add code for dual Stack (BLE, ESB) or SoftDevice cooperation, but Pull Requests to do this are welcome.

      If someone have plans to add BLE support, please look into the SoftDevice/DFU bootloader memory map. I think the DFU bootloader conflicts with the NVM library, which is used to store the MySensors configuration.

      posted in General Discussion
      d00616
      d00616
    • RE: nRF5 action!

      @Toyman said in nRF5 Bluetooth action!:

      For MYS, our only hope is d00616, if he doesn't do it, chances somebody will apapt 52840 to MYS are negligible.

      Please don't be so pessimistic. I expect some very small changes to MySensors to support the NRF52840 platform when arduino-nrf5 is ported to the new NRF5 MCU generation. When arduino-nrf5 supports the NRF52840 platform, I do some tests with the 840DK, I already have.

      Looking back to the NRF52832, I think in 6-9 month we can buy NRF52840 modules with production ready chips. I think there is no reason for panic.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      @d00616 What do you foresee regarding the nRF52840? It's presently unsupported.

      In those places where it was obvious, I took the design of the NRF52840 into consideration. I think, when an Arduino port supporting Sketches without SoftDevices is available, then porting is simple. At the moment, I have no plans to expedite an Arduino port.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      For instance, how hard would it be to create a simple serial bridge so view serial output on your bluetooth phone, the way @sundberg84 is doing with a specialized bluetooth module: https://forum.mysensors.org/topic/6340/debug-to-a-sd-card-module

      For similar functionality, there is an MY_DEBUG_OTA feature in MySensors development branch. You can send log messages to any node in the MySensors network.

      The NRF5 MySensors port is running directly on the MCU hardware. Using the SoftDevice is like running an Operating System. There are limitations using the Hardware and APIs have to use. You are loosing control over the Radio, some Timers and RTC, Crypto components and the memory layout.

      The reason the SoftDevice isn't supported is the old licence model. This model is changed with SDK14.

      In my opinion with MySensors 2.x it isn't meaningful to play with the multiplexing of the radio module. I think this requires more changes in MySensors to handle the time when the MCU is in BLE mode.

      If you are interested implementing a dual stack software, then I think the Arduino Primo port is a good point to start. This is based on the NRF5 SDK. The Primo port has no support for NRF51 devices.

      If you are not restricted to Arduino, you can also see MyNewt or Zephyr. Both have BLE Open Sorurce implementations for the NRF5 MCUs.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      @d00616 said in nRF5 Bluetooth action!:

      If you need help, please ask.

      What is it that I submit? A diff file or something? And I'm guessing I do it through github?

      There is and document describing the procedure: https://www.mysensors.org/download/contributing

      I think this is a good document to start with. If you have trouble, please ask.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @Toyman said in nRF5 Bluetooth action!:

      @d00616 said in nRF5 Bluetooth action!:

      Yes. Give the event register as parameter.

      so, if I have an intterupt atached to pin 1, what shall i put into ISR?

      With arduino-nrf5, you can't put nothing into the pin interrupt ISR because the ISR is already defined.

      Sorry for dumb questions, this is completely new to me.

      There are no dumb questions, there are bad answers.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      OK, I found that adding:
      NRF_UART0->ENABLE=0; //disable UART0

      brings the current consumption back down to 2.2ua during sleep.

      Great work. Are you able to build an Pull Request fixing this? This Pull request should also be tested in the condition with a disabled serial port.

      If you need help, please ask. I do the reviews.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @Toyman said in nRF5 Bluetooth action!:

      @d00616 thx. How do I use the macro? Just put in ISR?

      Yes. Give the event register as parameter.

      Regarding the bug: if read the docs correctly, all nrf51 have the bug

      This bug is listed as PAN#39 and fixed at the end of 2014.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      @d00616 said in nRF5 Bluetooth action!:

      The first available chip release has this type of bug.

      So, it's a hardware bug then? i.e. nothing can really be done about it for that chip release?

      There is a second method via GPIO -> pin sense for interrupt detection. This method requires less power, but you have to detect which pin is changed in software. Simulating a pin change interrupt is more complicated as detecting high or low level. I have started to do some researches and tests, but in my opinion it's to much work to support these outdated chip variants.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @Toyman said in nRF5 Bluetooth action!:

      What's the proper way to deal with interrupts on nrf?
      Many white areas:

      what pins have hardware interrupts? any?

      There is an limit in the number of monitored pins but not which pins are monitored.

      what about the macro mentioned in d00016 readme?

      This macro is required on NRF52 to read back event registers in interrupts. This clears the cache.

      how to overcome nrf51 bug of 1ma power consumption (code-wise)?
      Otherwise I see no reason buying nrf51 modules if they consume 1ma while sleeping

      This depends on the nRF51 chip release. The first available chip release has this type of bug. I prefer nRF52 because the chip is much more flexible with better radio characteristics.

      The flexibility of nRF5 MCUs starts with the interrupt vector in RAM. This allows to add bootloaders without adding latency or you can replace interrupts which are predefined in the arduino-nrf5 software.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @Jokgi said in nRF5 Bluetooth action!:

      @NeverDie Check out the new nRF52810. It is a stripped down version of the nRF52840.. Not as much memory and the peripherals are lower in count. But it has a Cortex M4 (Not F) and some of the targets are sensors, wearable, beacons, etc. On air compatible with nRF24L series and nRF52 series. Some limitations on BT 5.0 however.

      Where are the long range BLE modes? I think long range BLE modes are one of the best features of the 840 series.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      I'm not neutral ;-). I have ported MySensors to the NRF5 platform and completely reimplemented the NRF24 protocol, because at the point of starting Nordics License for the ESB protocol was not compatible with Open Source Licenses.

      @Omemanti said in nRF5 Bluetooth action!:

      Since this topic passed the 1000 posts, can someone tell me if the NRF5* , for mysensors, is worth diving into?

      I you are able to do more than described in the MySensors example sketches, you should give it a try. It's a little bit more complicated than starting with ATMEGA based boards.

      And could someone be so kind, to sum up some pro/cons?

      Pros:

      • Enough Flash and RAM
      • Faster CPU
      • periphery can do a lot of things while the CPU is sleeping (PPI, SHORTS)
      • Small footprint of sensors
      • Mostly free pin mapping in your Sketch
      • NRF24 compatible
      • Same price like ATMEGA + NRF24
      • No bad clones like NRF24
      • Better range than NRF24 (
      • Flexibility to change the radio protocol
      • BLE Long range, USB with the upcomming NRF52840
      • Most complete 32 Bit implementation for MySensors (at the moment) supporting sleep(), hardware random numbers, soft signing and an internal EEPROM emulation without additional hardware.
      • Great hardware included
      • Can be mixed with other radio modules like NRF24 (useless but tested) or RFM (untested)
      • Enough resources for better security concepts
      • No need for ATSHA204 when you don't require read back protection. Enabling read back protection depends on OTA updates, which are not implemented at the moment.
      • Well documented MCU's

      Cons:

      • Not all Arduino functionality available like EEPROM (available in MySensors or externaly via emulation), Tone library
      • Maybe some bugs in the arduino implementation or radio implementation
      • OTA firmware update is missing for MySensors, but it's possible
      • BLE with MySensors is not supported/tested at the moment. I think BLE support needs a little bit of porting code to SoftDevice API
      • Beta: Needs field testing
      • Multiple NRF5 Arduino ports like (arduino-NRF5 or Primo). Only arduino-nrf5 without SoftDevice is supported at the moment.

      Neutral:

      • Radio is for 2.4GHz only which means less regulations but shorter transmit distance
      • The NRF24 protocol isn't a good protocol for encryption or battery powered nodes permanently listening for packages, the protocol can be replaced in 100% NRF5 networks in the future

      I think there is no future for 8 Bit Controllers in the Arduino world. If you want to do more without diving into the PROGMEM hell, then it's time to switch to 32 bit controllers. The NRF5 is an interesting and highly integrated choice for 2.4GHz networks.

      My small home network is completely NRF5 based. From time to time a node stops receiving packages. The problem is known and documented by Nordic. I working on a fix.

      There are some differences in timing between NRF24 and NRF5 which are no problem, I think. The NRF24 is ~12ยตs earlier in RX mode and the NRF5 is ~400ยตS earlier in TX mode. If this is a problem, it's catched by a retransmit. Instead of tuning this protocol, I think it's better to invest the time in creating a protocol which allows battery powered nodes to listen for packages and allowing better security than the NRF24 ESB protocol.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      @d00616
      I want to transmit the shortest frame possible for my remote control packet, because that means the listen window on the receiver can be as short as possible, and that equals energy savings.

      I think the best way to do this is using the Bit counter. Set a timer to stop the radio and with the bitcounter, you can stop this timer. With the BC, you don't loose the CRC or length information. The Bit counter counts the S0/S1 and Length information and all data bits.

      I use the bitcounter in the ESB-TX mode.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Looking at the nRF24L01 datasheet (file:///C:/Users/CoolerMaster/Downloads/nRF24L01_Product_Specification_v2_0%20(3).pdf), it appears that one simply needs to keep the TX FIFO full, and the radio will then send things as fast as it can (which should be a lot faster than 27ms). So, I'll give that a try.

      If "noACK" is enabled, each packet is send 15 times, which consumes ~27ms. Both NRF24 and NRF5 do the same here.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Thanks for trying. That would probably work with a linux machine, but mine is running Windows. I'm surprised there's no easy way to do this from Windows.
      I guess I'll just wait for the next developers release of mysensors.

      This depends on Git installed not on Linux. The Pull Request is now into the developer branch.

      @NeverDie said in nRF5 Bluetooth action!:

      However, the serial output of the pro mini often seems to include a 1-byte packet:
      ...
      Is that a bug?

      This is the RSSI value, which is send back as ACK payload. I check what's the best way to deal with.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Maybe I need write-access or something? Those instructions refer to a command line, and I just don't see one anywhere.

      You can do this with git on your local machine:

      git clone https://github.com/mysensors/MySensors.git
      cd MySensors
      git fetch origin pull/938/head:pr938
      git checkout pr938
      
      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      That link lists changes to the files, but it doesn't seem to provide the new files. Or else I'm overlooking where it does?

      You have to checkout this pull request: https://help.github.com/articles/checking-out-pull-requests-locally/

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @d00616 said in nRF5 Bluetooth action!:

      At the moment I prepare a new Pull Request fixing this including some small fixes and improvements for nRF5 MCUs. When it's integrated the HFCLK is startet in hwInit().

      The Pull Request is available: https://github.com/mysensors/MySensors/pull/938

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @Toyman said in nRF5 Bluetooth action!:

      @d00616 is this universal recommendation?

      I think you mean to start the HFCLK. This isn't a universal recommendation. At the moment the HFCLK is started in MyMainNRF5.cpp. This file is ignored in CORE_ONLY mode. I moved any initialization code into hwInit().

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Since the original code didn't work, I upgraded it somewhat to give a larger Rx window. However, it still doesn't work:

      Please add this to your setup() function (https://forum.mysensors.org/topic/6961/nrf5-bluetooth-action/985๐Ÿ˜ž

      	// Clock is manged by sleep modes. Radio depends on HFCLK.
      	// Force to start HFCLK
      	NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
      	NRF_CLOCK->TASKS_HFCLKSTART = 1;
      	while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0)
      		;
      
      	// Enable low latency sleep mode
      	NRF_POWER->TASKS_CONSTLAT = 1;
      
      	// Enable cache on >= NRF52
      #ifndef NRF51
      	NRF_NVMC->ICACHECNF = NVMC_ICACHECNF_CACHEEN_Msk;
      #endif
      

      At the moment I prepare a new Pull Request fixing this including some small fixes and improvements for nRF5 MCUs. When it's integrated the HFCLK is startet in hwInit().

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      I just now tried running it on a pro-mini using a nRF24, and it also gets into a boot-loop.

      Please replace wait() with delay(). This is an issue in the transport code, which is triggered while sleep() or wait() is executed.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      I just now upgraded to the current release of the mysensors development library, and the compile problem went away. So, if anyone else encounters the same problem, I recommend doing that.

      Sorry. I have forgotten my uncommited changes. At the moment, you have to start the HFCLK in the CORE_ONLY mode. This is done in hwInit() later.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      I tried compiling it using the Arduino Windows IDE, but for some reason it complains about not finding a whole litany of .h files: socket.h, w5100.h, netdb.h.... Does mysensors.h really need to drag in all of those .h files, even if only indirectly? Or, if there's an easy way to make it find them, what is it?

      I can compile it with Linux. What are missing is part of the Ethernet library. I don't know why it's included in you build.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Yes, and thanks to @d00616's work, RESET can also be enabled/disabled from the Tools menu of the arduino IDE if using myNRF5Board as the board definition.

      The reset support isn't complete at the moment. The menu is active, but it has no effect at the moment. I fix this with release 0.2.0.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Which settings are key for ensuring that packets sent by the nRF24 are correctly received by the nRF5? It would be nice to leverage the versions of the nRF24 that have amplified Tx.

      These are more than settings. You have to set the Radio configuration like in Radio_ESB.cpp, reverse the addresses and handle sending ACK packages by software.

      This is a good resource to understand the OTA protocol: https://hackaday.io/project/11942-antenna-diversity-receive-and-transmit/log/39510-shockburst-vs-enhanced-shockburst-nrf24-vs-nrf5x

      I can provide a simple example how to use the MySensors transport code without Radio Head. This works for nRF5 and nRF24 modules, but its outside of that what the MY_CORE_ONLY mode is designed for.

      #define MY_CORE_ONLY
      
      #ifndef ARDUINO_ARCH_NRF5
      #define MY_NODE_ID (1)
      #define SND_TO (2)
      #else
      #define MY_NODE_ID (2)
      #define SND_TO (1)
      #endif
      
      // Enable debug
      #define MY_DEBUG
      //#define MY_DEBUG_VERBOSE_RF24
      //#define MY_DEBUG_VERBOSE_NRF5_ESB
      
      
      // RF24_250KBPS RF24_1MBPS RF24_2MBPS
      #define MY_RF24_DATARATE (RF24_1MBPS)
      // NRF5_250KBPS NRF5_1MBPS NRF5_2MBPS
      #define MY_NRF5_ESB_MODE (NRF5_1MBPS)
      
      
      // Enable and select radio type attached
      #ifndef NRF5
      #define MY_RADIO_NRF24
      #else
      #define MY_RADIO_NRF5_ESB
      #endif
      
      #include <MySensors.h>
      
      void setup() {
        Serial.begin(115200);
        
        hwInit();
        transportInit();
        transportSetAddress(MY_NODE_ID);
      }
      
      void loop() {
        // Check for packages
        while (transportAvailable()) {
          uint8_t buffer[256];
          uint8_t num = transportReceive(&buffer);
          Serial.print("Data=");
          for (int i=0;i<num;i++) {
            if (buffer[i]<0x10) Serial.print("0");
            Serial.print(buffer[i], HEX);
            Serial.print(" ");
          }
          Serial.println();
        }
      
        wait(1000);
      
        // Send data
        transportSend(SND_TO, "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",32, false);
      }
      
      posted in My Project
      d00616
      d00616
    • RE: nRF5 Multi Sensor Board (12-14โ‚ฌ)

      @Ptibu said in nRF5 Multi Sensor Board (12-14โ‚ฌ):

      @MiKa Here is my sketch if it helps. It uses ALS, BMP180 and RGB leds.
      Working well with my nRF24 LNA+PA GW.

      Thank you sharing your sketch. You can use https://github.com/mysensors/ArduinoHwNRF5 to redefine pin mappings in your sketch.

      posted in Hardware
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Now listening every 100ms yields a 10F supercap voltage measured decline of just 9mv per hour. i.e. a decline of 0.108v by the end of 12 hours.

      Great job. If I'm not wrong the method allows nearly 1 year of listening time with a CR2032.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @Mike_Lemo said in nRF5 Bluetooth action!:

      Also about the NFC I'm planning to use it with the arduino IDE so just wanted to ask if there is a library for it because the SDK is quite useless in this case as well as the Central peripheral connection.

      Now there is a second port of arduino to nRF52. This includes some libraries, like NFC, but they using the SDK. MySensors is currently not ready for this arduino-port.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @Mike_Lemo said in nRF5 Bluetooth action!:

      Where is it possible to find a reference schematic for using the NTF52832 E73-2G4M04S module with NFC?
      not much is being given in the datasheet not even where the NFC pins go.

      Please look into the product documentation:
      http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/nfc.html?cp=2_1_0_41_8#concept_ryw_4hk_1s

      @NeverDie said in nRF5 Bluetooth action!:

      At the moment on Arduino, there is no definition of various OUTPUT modes. If you want to access all nRF5 output modes, you have to use hwPinMode and the OUTPUT_... macro.

      Exactly which macro would that be? It looks to me as though what most users will want is the function nrf5_pinmode(..,..), which appears to do all the actual work. Is that right? It is defined in the file nrf5_wiring_digital.c.

      hwPinMode allows to define platform specific PinMode replacements. Code may be portable. This is the reason pointing to nrf5_pinmode().

      nrf5_pinmode() has a little bit more functionality than the original pinmode function.

      Meanwhile, hwPinMode appears to be merely a straight pass-through for pinMode:

      void hwPinMode(uint8_t pin, uint8_t mode)
      {
      pinMode(pin, mode);
      }

      This disables the capability using nRF5 specific pin modes with the MySensors API.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      @d00616
      Can you see any reason as to why the radio isn't waking the MCU after it receives a packet? Here's the entire sketch:

      I have no Idea why. The code is looking fine.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @d00616 said in nRF5 Bluetooth action!:

      Maybe someone has an idea about the reason. Here is my code for nRF5 and other with nRF24.

      Now, I have the NRF5_ESB working under MY_CORE_ONLY condition. The HFCLK is not initialized. I do some code changes to allow using the radio in core only mode.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Whenever I use:
      #include <MySensors.h>

      on the nRF52832, there is around a 10 second delay between the end of "void startup()" and the beginning of "loop()". Why is that, and what is the MySensors library doing during that interval?

      As an alternative, you can define '#define MY_CORE_ONLY' and use ' transportInit(); transportSetAddress(MY_NODE_ID);' to initialize the radio. This dosn't work at the moment with the nRF5. I'm currently looking what the reason is. All radio registers are equal when it's initialized after MySensors normal and my setup(). It's not able to send or receive packages.

      Maybe someone has an idea about the reason. Here is my code for nRF5 and other with nRF24.

      // Undefine to work in gateway mode
      #define MY_CORE_ONLY
      
      
      #define MY_NODE_ID (0)
      
      // Enable debug
      #define MY_DEBUG
      #define MY_DEBUG_VERBOSE_RF24
      #define MY_DEBUG_VERBOSE_NRF5_ESB
      
      // Enable and select radio type attached
      #ifndef ARDUINO_ARCH_NRF5
      #define MY_RADIO_NRF24
      #else
      #define MY_RADIO_NRF5_ESB
      #include <nrf.h>
      #endif
      //#define MY_RADIO_RFM69
      //#define MY_RADIO_RFM95
      
      //#define MY_OTA_LOG_SENDER_FEATURE
      //#define MY_OTA_LOG_RECEIVER_FEATURE
      
      #ifndef MY_CORE_ONLY
      #define MY_GATEWAY_SERIAL
      #endif
      #include <MySensors.h>
      
      void state() {
      #ifdef ARDUINO_ARCH_NRF5
       Serial.println("----------------------------------");
       Serial.print("NRF_RADIO->STATE  ");
       Serial.println(NRF_RADIO->STATE, HEX);
       Serial.print("NRF_RADIO->EVENTS_READY  ");
       Serial.println(NRF_RADIO->EVENTS_READY, HEX);
       Serial.print("NRF_RADIO->EVENTS_ADDRESS  ");
       Serial.println(NRF_RADIO->EVENTS_ADDRESS, HEX);
       Serial.print("NRF_RADIO->EVENTS_PAYLOAD  ");
       Serial.println(NRF_RADIO->EVENTS_PAYLOAD, HEX);
       Serial.print("NRF_RADIO->EVENTS_END  ");
       Serial.println(NRF_RADIO->EVENTS_END, HEX);
       Serial.print("NRF_RADIO->EVENTS_DISABLED  ");
       Serial.println(NRF_RADIO->EVENTS_DISABLED, HEX);
       Serial.print("NRF_RADIO->EVENTS_DEVMATCH  ");
       Serial.println(NRF_RADIO->EVENTS_DEVMATCH, HEX);
       Serial.print("NRF_RADIO->EVENTS_DEVMISS  ");
       Serial.println(NRF_RADIO->EVENTS_DEVMISS, HEX);
       Serial.print("NRF_RADIO->EVENTS_RSSIEND  ");
       Serial.println(NRF_RADIO->EVENTS_RSSIEND, HEX);
       Serial.print("NRF_RADIO->EVENTS_BCMATCH  ");
       Serial.println(NRF_RADIO->EVENTS_BCMATCH, HEX);
       Serial.print("NRF_RADIO->CRCSTATUS  ");
       Serial.println(NRF_RADIO->CRCSTATUS, HEX);
       Serial.print("NRF_RADIO->RXMATCH  ");
       Serial.println(NRF_RADIO->RXMATCH, HEX);
       Serial.print("NRF_RADIO->RXCRC  ");
       Serial.println(NRF_RADIO->RXCRC, HEX);
       Serial.print("NRF_RADIO->DAI  ");
       Serial.println(NRF_RADIO->DAI, HEX);
       Serial.print("NRF_RADIO->PACKETPTR  ");
       Serial.println(NRF_RADIO->PACKETPTR, HEX);
       Serial.print("NRF_RADIO->FREQUENCY  ");
       Serial.println(NRF_RADIO->FREQUENCY, HEX);
       Serial.print("NRF_RADIO->TXPOWER  ");
       Serial.println(NRF_RADIO->TXPOWER, HEX);
       Serial.print("NRF_RADIO->MODE  ");
       Serial.println(NRF_RADIO->MODE, HEX);
       Serial.print("NRF_RADIO->PCNF0  ");
       Serial.println(NRF_RADIO->PCNF0, HEX);
       Serial.print("NRF_RADIO->PCNF1  ");
       Serial.println(NRF_RADIO->PCNF1, HEX);
       Serial.print("NRF_RADIO->BASE0  ");
       Serial.println(NRF_RADIO->BASE0, HEX);
       Serial.print("NRF_RADIO->BASE1  ");
       Serial.println(NRF_RADIO->BASE1, HEX);
       Serial.print("NRF_RADIO->PREFIX0  ");
       Serial.println(NRF_RADIO->PREFIX0, HEX);
       Serial.print("NRF_RADIO->PREFIX1  ");
       Serial.println(NRF_RADIO->PREFIX1, HEX);
       Serial.print("NRF_RADIO->TXADDRESS  ");
       Serial.println(NRF_RADIO->TXADDRESS, HEX);
       Serial.print("NRF_RADIO->RXADDRESSES  ");
       Serial.println(NRF_RADIO->RXADDRESSES, HEX);
       Serial.print("NRF_RADIO->CRCCNF  ");
       Serial.println(NRF_RADIO->CRCCNF, HEX);
       Serial.print("NRF_RADIO->SHORTS  ");
       Serial.println(NRF_RADIO->SHORTS, HEX);
       Serial.print("NRF5_RADIO_TIMER->MODE ");
       Serial.println(NRF5_RADIO_TIMER->MODE);
       Serial.print("NRF5_RADIO_TIMER->BITMODE ");
       Serial.println(NRF5_RADIO_TIMER->BITMODE);
       Serial.print("NRF5_RADIO_TIMER->SHORTS ");
       Serial.println(NRF5_RADIO_TIMER->SHORTS);
       Serial.print("NRF5_RADIO_TIMER->PRESCALER ");
       Serial.println(NRF5_RADIO_TIMER->PRESCALER);
        // Reset compare events
      #ifdef NRF51
        for (uint8_t i=0;i<4;i++) {
      #else
        for (uint8_t i=0;i<6;i++) {
      #endif
       Serial.print("NRF5_RADIO_TIMER->EVENTS_COMPARE[");
       Serial.print(i);
       Serial.print("] ");
       Serial.println(NRF5_RADIO_TIMER->EVENTS_COMPARE[i]);
      }
      Serial.println("----------------------------------");
      #endif
      }
      
      void setup() {
        Serial.begin(115200);
        
        #ifdef MY_CORE_ONLY
        transportInit();
        delay(1000);
        transportSetAddress(MY_NODE_ID);
        #endif
      }
      
      void loop() {
        state();
      
        #ifdef MY_CORE_ONLY
        // Check for packages
        if (transportAvailable()) {
          uint8_t buffer[256];
          uint8_t num = transportReceive(&buffer);
          for (int i=0;i<num;i++) {
            if (buffer[i]<0x10) Serial.print("0");
            Serial.print(buffer[i], HEX);
            Serial.print(" ");
          }
          Serial.println();
        }
        #endif
      
        // Pause
        //sleep(1000); don't use this on SAMD. The device must be restored with reset doubleclick
        delay(1000);
        
        // Send data
        //transportSend(MY_NODE_ID, "abcd", 4, false);
      }
      

      @NeverDie said in nRF5 Bluetooth action!:

      @d00616 said in nRF5 Bluetooth action!:

      P.S.: you can reduce the RX/TX time by enabling fast ramp up in MODECNF0 if you haven't to care about nRF51 compatibility.

      Thanks for the tip. I tried it both ways. The first scope capture below is taken without MODECNF0 enabled on bit 0, and the second is with it enabled on bit 0.

      Have you checked the MODECNF0 register after ramp up? Maybe the register must be changed in a specific state?

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Question: Is
      NRF5_RESET_EVENT(NRF_RADIO->EVENTS_PAYLOAD);

      doing anything more than
      NRF_RADIO->EVENTS_PAYLOAD=0;

      is?

      Yes. It reads back the register. http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52/dita/nrf52/migration/functional.html?cp=2_4_0

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Are we limited to using RTC0? I've tried switching to RTC1 and RTC2, and I get the sense there are conflicts with both of them and the MySensors code if they're used.

      RTC1 is blocked by arduino (nRF5/delay.c) and RTC0 (nRF51) and RTC2 (nRF52) is used in MySensors (hal/architecture/MyHwNRF5.cpp)

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:
      If your goal is to minimize the RX-on time, then you can trigger the RX start and stop by a timer for your minimal window where the frame must be start. Then use the bitcounter top stop the timer in case a packet is received. A shortcut to the end is disabling the RX mode. You can wakeup the CPU with the END event.

      P.S.: you can reduce the RX/TX time by enabling fast ramp up in MODECNF0 if you haven't to care about nRF51 compatibility.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      to sleep the CPU while keeping the PPI active, is there a way for the PPI to subsequently wake the CPU so that the CPU can resume where it left off? I'm not seeing any TASKS which look suitable for doing that. Or do I need an altogether different configuration for sleeping the CPU?

      The PPI cannot wake up the CPU. You can try to trigger events to a timer which resumes the CPU.

      @NeverDie said in nRF5 Bluetooth action!:

      Are there special reserved names to always use for the IRQ handlers? e.g. GPIOTE_IRQHandler(void), and so on?

      The names are defined there:

      https://github.com/sandeepmistry/arduino-nRF5/blob/dc53980c8bac27898fca90d8ecb268e11111edc1/cores/nRF5/SDK/components/device/nrf52.h#L65

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      I am posting my findings as I go because there is precious little in the way of working examples, so I may yet still be of help to others in that way. From the view count, it does seem that people are reading this thread, even if not many are posting.

      btw. Thank you for sharing you knowledge here. In my option this is very helpful for me.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Anyhow, I don't see a way to do an RFM69 style "listen mode" using just the PPI on the nRF52832. I think this may be a dead end.

      It looks like you are implementing a new radio protocol and you are coming forward.

      What do you think about forking the MY_RADIO_NRF5_ESB into a new one? The nRF5 code is designed to implement additional protocols for nRF5.

      If you remove the address reverse code, there are no OTA conflicts with the ESB protocol. The address width can be enhanced by 2 bits to allow better AES encryption and lager packages.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Is there any example code which illustrates the use of interrupts on the nRF52832?

      Yes. In a sketch, you have to put the interrupt routine into one line. You can define the interrupt only once. If you want to use the radio ISR, you can't enable the radio in MySensors.

      https://github.com/sandeepmistry/arduino-nRF5/issues/52

      https://github.com/mysensors/MySensors/blob/development/drivers/NRF5/Radio_ESB.cpp#L500

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      So, to make the above code work as a PPI, all I would need is some kind of linkage such that whenever the "event" of TXIDLE occurs, then a "task" (in this case it would be TASKS_START) is executed to move the radio back into the TX state.

      This is a use case for shortcuts. PPI is not required.

      There is no TXIDLE event but looking at the state diagram is TXIDLE a result of ether READY or END event. You can enable following shortcurts:

      NRF_RADIO->SHORTS = RADIO_SHORTS_READY_START_Msk | RADIO_SHORTS_END_START_Msk;
      

      In PPI this should be the code (untested):

      #define CHANNEL (1)
      NRF_PPI->CH[CHANNEL].EEP = (uint32_t)&NRF_RADIO->EVENTS_END;
      NRF_PPI->CH[CHANNEL].TEP = (uint32_t)&NRF_RADIO->TASKS_START;
      NRF_PPI->CH[CHANNEL+1].EEP = (uint32_t)&NRF_RADIO->EVENTS_READY;
      NRF_PPI->CH[CHANNEL]+1.TEP = (uint32_t)&NRF_RADIO->TASKS_START;
      NRF_PPI->CHENSET = (1 << CHANNEL) | (1 <<( CHANNEL+1));
      
      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie Thank you sharing your experience here. It helps me of better understanding some nRF5 internals. It would be awesome if you share your code.

      @NeverDie said in nRF5 Bluetooth action!:

      Do you know of any good PPI tutorials? The datasheet seems awfully skimpy on its explanation of exactly how to use it.

      To understand PPI you have to be in mind that nearly everything is driven by tasks and events. If you want to do something, you have to start a task like 'NRF_RADIO->TASKS_TXEN=1'. If a task ends it generates an event like 'NRF_RADIO->EVENTS_READY'. You can replace NRF_RADIO with another periphery the registers have an equal naming scheme.

      For an event an Interrupt can be enabled with the NRF_RADIO->INTENSET register. Each event correspondents with a bit in that register. In an interrupt, you have to reset the NRF_RADIO->EVENTS_READY register to 0 to allow triggering a new interrupt. For compatibility, you can use the NRF_RESET_EVENT macro in interrupts. This reads back the register on nRF52 to avoid caching effects. Interrupts doesn't matter for PPI ๐Ÿ™‚

      The next fine thing are Shortcuts. Shortcuts are limited to the same peripheral unit. Bits in the NRF_RADIO->SHORTS register are corresponding to a connection between an event and a test. If the event is triggered the task is started. This allows to trigger things like send an packet after the radio is ready. To use this, you have to enable the shortcut in the NRF_RADIO->SHORTS register.

      To break the limits of shortcuts, there is the PPI unit with 32 channels. Some of the channels are predefined but interesting to see how things are implemented with BLE. The other PPI channels are flexible. To use one of these channels, you have to write a pointer of your event register, like '(uint32_t)&NRF_RADIO->EVENTS_END' to the NRF_PPI->CH[YOUR_CHANNEL].EEP register and a pointer to your task you want to start in the NRF_PPI->CH[YOUR_CHANNEL].TEP register like '(uint32_t)&NRF_TIMER0->TASKS_START'. Then you have to enable the PPI channel by setting the corresponding bit like 'NRF_PPI->CHENSET |= (1 << COUR_CHANNEL)' that's all.

      The nRF52, but not the nRF52 comes with NRF_PPI->FORK[YOUR_CHANNEL].TEP registers. in my reading you can start a second task with this register like writing to NRF_PPI->CH[YOUR_CHANNEL].TEP.

      I have no idea about using the PPI Groups.

      Arudino provides a PPI library for the primo: http://cdn.devarduino.org/learning/reference/ppi I think we have to use this library to be compatible in the future. I hope there is a chance to port things to arduino-nrf5 back.

      Edit: The arduino PPI library is not flexible enough to support radio events. ๐Ÿ˜ž

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      The datasheet is possibly a bit misleading when it says:

      For the RSSI sample to be valid the radio has to be enabled in receive mode (RXEN task) and the reception
      has to be started (READY event followed by START task).

      I'm finding that the radio needs to be in either RXIDLE state or RX state to get a plausible RSSI measurement. I can't get a reasonable RSSI measurement while within the RXEN state.

      In the ESB code, I use the bitcounter event to start the rssi sample task via PPI. The results are looking plausible.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      @mfalkvidd said in nRF5 Bluetooth action!:

      So the value is 0xFFFFFFFF. That often means uninitialized. I don't know why it would be uninitialized though.

      There's a chance we may have unwittingly done it ourselves! Remember back to when we were doing an explicit "Erase All"? From the datasheet:

      This is part of the arduino-nrf5 code -> https://github.com/sandeepmistry/arduino-nRF5/blob/dc53980c8bac27898fca90d8ecb268e11111edc1/cores/nRF5/SDK/components/toolchain/system_nrf52.c#L156

      I don't have any idea why this is not included in the binary. When the reset menu is selected then "-DCONFIG_GPIO_AS_PINRESET" is given to gcc.

      When system_nrf52.c is completely ignored, then the erratas are not handled.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Actually, even just sleeping the MCU with a simple command like:
      sleep(100);

      is apparently enough to require a re-init of the radio afterward. Not sure why that would be.

      sleep() deinitializes the transport with transportDisable(). This results in power down the radio.

      At the moment I review the ESB code. I think the nRF5 is 12-13ยตs after an nRF24 in RX mode and 432ยตs before an nRF24 in TX. This can result in unstable connections when debug messages are disabled.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      @d00616 said in nRF5 Bluetooth action!:

      @NeverDie said in nRF5 Bluetooth action!:

      Here's the mode that I'm most interested in: Putting the radio into Rx for about 1ms per 100ms interval to listen for remote commands. The rest of the time everthing (both radio and mcu) are in deep sleep waiting for the RTC to wake them up.

      When you take a look into the PPI section, you are able to let the CPU sleep until a radio packet is received. With PPI, the listen mode can be activated and deactivated without CPU interaction.
      The nRF5 MCUs are able to to a lot of things without waking up the CPU. That's a really cool feature.

      Sounds like it has potential. Any demo code for this? The datasheet seems a bit sketchy.

      These are some snippets of the radio code. There are fully useable PPI and some predefined. For fully useable PPI into the EEP register, you put the address of an EVENT register and in the TEP register, you put the pointer to an TASK register.

         /** Configure PPI (Programmable peripheral interconnect) */
          // Start timer on END event
          NRF_PPI->CH[NRF5_ESB_PPI_TIMER_START].EEP = (uint32_t)&NRF_RADIO->EVENTS_END;
          NRF_PPI->CH[NRF5_ESB_PPI_TIMER_START].TEP = (uint32_t)&NRF5_RADIO_TIMER->TASKS_START;
          // Disable Radio after CC[0]
          NRF_PPI->CH[NRF5_ESB_PPI_TIMER_RADIO_DISABLE].EEP = (uint32_t)&NRF5_RADIO_TIMER->EVENTS_COMPARE[0];
          NRF_PPI->CH[NRF5_ESB_PPI_TIMER_RADIO_DISABLE].TEP = (uint32_t)&NRF_RADIO->TASKS_DISABLE;
          ...
          // Set PPI
           NRF_PPI->CHENSET = NRF5_ESB_PPI_BITS;
          ...
        // Clear PPI
          NRF_PPI->CHENCLR = NRF5_ESB_PPI_BITS;
      

      Then you have to enable or disable the register. It could be necessary to reset the events. You can use the NRF_RESET_EVENT macro to do this job.

       NRF_RESET_EVENT(NRF5_RADIO_TIMER->EVENTS_COMPARE[0]);
      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      Here's the mode that I'm most interested in: Putting the radio into Rx for about 1ms per 100ms interval to listen for remote commands. The rest of the time everthing (both radio and mcu) are in deep sleep waiting for the RTC to wake them up.

      When you take a look into the PPI section, you are able to let the CPU sleep until a radio packet is received. With PPI, the listen mode can be activated and deactivated without CPU interaction.

      The nRF5 MCUs are able to to a lot of things without waking up the CPU. That's a really cool feature.

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @NeverDie said in nRF5 Bluetooth action!:

      As a follow-up to rmtucker's line of inquiry, what is currently the shortest deep sleep that's supported? Is it one millisecond, or something else?

      Why do you need this type of short sleeps?

      Sleep is for battery powered devices. A device that wakes up more than 1000 times in the second might be hard to drive with a battery.

      @rmtucker said in nRF5 Bluetooth action!:

      @NeverDie
      Theoretically it is 2 clock ticks at 32768khz so 0.000061035secs i think.

      This is correct.

      But how long it takes to go into sleep mode and come out of sleep mode i am not sure.

      It's simple to evaluate with micros() before and after a sleep().

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @d00616 said in nRF5 Bluetooth action!:

      Actually I check the result of sleep(511999) and sleep(512001). When it's finished I fix that in MySensors.

      Is fixed in development branch.
      https://github.com/mysensors/MySensors/pull/917

      posted in My Project
      d00616
      d00616
    • RE: nRF5 action!

      @scalz said in nRF5 Bluetooth action!:

      @d00616 said in nRF5 Bluetooth action!:

      Should I add a DISCONNECTED mode to hwPinMode()?

      make sense to have it for input too.. i agree

      What's the best name for this mode? DISCONNECTED or INPUT_DISCONNECTED. I prefer the first variant.

      I have to play a little bit with the port modes. Maybe it saves some current when the serial port pins are put into the disconnected mode while sleeping.

      posted in My Project
      d00616
      d00616