Ok got it, you seems to power the sensor leaving 3V3 and connecting GND on demand, you’re lucky not having any drawn current due to internal circuit
Since power of the sensor is the same level of GPIO out, I will do the same on reverse side, leaving GND connected and power VDD
My choice of switching on the low side was to have it off when there is no current on the GPIO. The idea of having to maintain the GPIO high to have the sensor off didn’t sound right to me. But of course it makes sense with an external pull-up which won’t draw much current…
Both makes sense, but I had some issues in the past leaving VDD connected to sensors (depending on sensors of course but mainly I2C ones). Correct, about the draw, but as soon as the GPIO is set as output high should be okay to consume nothing? but may be I’m missing something, so experts can answer, I will be glad to know this point.
My point was that using a P channel MOSFET, you need to maintain the gate high all the time when the device sleeps, while using an N channel logic you only have to pull the gate high when you want to power your sensor…
(But again, i am not an hardware guy, I probably jumped to conclusion too fast…)
In the last version (1.6 IIRC) released by IBM, the license was changed from EPL to MIT (IIRC). I asked them to do so, since EPL is not GPL-compatible. I have never gotten around to updating my version to that latest version, which makes my version still EPL.
So you requested IBM to change their license but failed to update your own? 
I guess updating your license will only require updating some headers and adding a proper LICENSE.txt on your github repo GitHub - matthijskooijman/arduino-lmic: ⚠ This library is deprecated, see the README for alternatives. ?
(1.6 was a license update only?)
BTW: GitHub - mcci-catena/arduino-lmic: LoraWAN-MAC-in-C library, adapted to run under the Arduino environment (already) uses MIT license.
Do you use this lib? I tried to replace my old one (GitHub - things-nyc/arduino-lmic: LoraWAN-in-C library, adapted to run under the Arduino environment) which is working fine but changing to catena does not work right out of the box on my code, so I’m asking. I also noticed the new one use much much more flash and ram.
Yes, since recently as this appears to be the one that is still maintained and contains several improvements/fixes (compared to GitHub - matthijskooijman/arduino-lmic: ⚠ This library is deprecated, see the README for alternatives.). It also provides support for more regions/ISM band frequencies so your code can be used by more people around the globe.
Also see: Overview of LoRaWAN Libraries [HowTo]
Correct. ‘MCCI LoRaWAN LMIC library’ defines CFG_us915=1 as default in configuration file lmic_project_config.h which is very probably the cause for not working out of the box.
I.m.o. MCCI LoRaWAN LMIC library should not set any default region frequency because this is error prone while the user is unaware of the cause. Instead the user should explicitly have to select this (without a default) and a compilation error should be given if not done yet.
lmic_project_config.h defines project scoped settings at library sourcecode level instead of project level. Changing settings in lmic_project_config.h requires modification of library sourcecode which is maintenance intensive, error prone and difficult to automate.
A serious problem with this construct is that changes made to lmic_project_config.h will be silently overwritten with every library update. Luckily when using PlatformIO we can do these settings in platformio.ini which is not impacted by library updates.
The MCCI LoRaWAN LMIC library supports a build flag to suppress the use of lmic_project_config.h.
This build flag makes possible to define library build options in platformio.ini instead of lmic_project_config.h.
Example platformio.ini with support for MCCI LoRaWAN LMIC library:
; File: platformio.ini
[env:lora32u4II]
platform = atmelavr
board = lora32u4II
framework = arduino
monitor_speed = 115200
lib_deps =
MCCI LoRaWAN LMIC library
build_flags =
; *** LMIC library build options: ***
; -D DISABLE_PING
; -D DISABLE_BEACONS
; -D LMIC_DEBUG_LEVEL=2
; -D LMIC_PRINTF_TO=Serial
; *** MCCI LoRaWAN LMIC library specific build options: ***
; Set suppress flag to suppress lmic_project_config.h
; to allow project related settings to be defined here instead.
-D ARDUINO_LMIC_PROJECT_CONFIG_H_SUPPRESS
; -D CFG_in866=1
-D CFG_eu868=1
; -D CFG_us915=1
; -D CFG_au921=1
; -D CFG_as923=1
; -D LMIC_COUNTRY_CODE LMIC_COUNTRY_CODE_JP ; for as923-JP
-D CFG_sx1276_radio=1
; -D LMIC_USE_INTERRUPTS
Note: The recently released PlatformIO Core 4.0 has introduced directory structure changes. You may possibly have to update projects after upgrading to Core 4.0 (e.g. deleting .piolibdeps directory).
Yup, I wanted to significantly change the way I ported the library as part of the 1.6 update, but never found the time for that.
I had not noticed the difference, because I have not (yet) checked/compared it’s memory use.
BTW: as a workaround you may disable PING and BEACONS (see my above platformio.ini) to get more available memory (useful for AVR).
or change the bootloader … saves a few bytes (AVR)
I’m sure it’s the best one 
I noticed size because with ULPNode lib (and some sensors) got warning about RAM usage at compilation, and even does not fit to flash (I have optiboot of course and had disabled PING and BEACONS, I needed to disable debug in my code to be able to fit) and may be that’s what is causing my hazardous reset by lack of RAM, but I had no time to check this so reversed to old one. Also new one add 2 new events that I need to manage.
About the mosfet to drive power for sensor; what about this implementation using TPL chip
Which one do you prefer? controling mosfet by TPL D3 like this schematic or by another GPIO only like previous post above?
Can you make it selectable via a bridge?
In my use case, I prefer a separate GPIO as I can then keep the power on time shorter, just the time needed to collect data, not the time spent in sending and other housekeeping…
But I can see other use cases where you want to keep it simple and save a GPIO port…
Not sure I see the difference, when you go into sleep mode you need to be sure the logic state of the driving pin is such that the device is off, be that high or low.
If you use low side switching, you can create a situation where your devices are phantom powered through I\O pins.
I think this is what I’m having problems with, why I can’t get my TPL/wakeup to work on my mini-lora v1.2 boards.
(I have so far not been successful with the ULP-node code as a base).
@Amedee, do you have some code to share to show how to do “non hardware IRQ TPL”?
@Basse you can do a dirty hack connect A2 (TPL pin) to A0, A1 or A3) this mean that TPL pin goes to A2 and for example A1 (so let A2 as input)
Then take a look at the sample code wake_buton.ino and add the new IRQ IRQ_SENSOR_A1_ENABLE to wake
// Light off LEDs, remove power from sensors and RF modules
ulpn.RGBShow(RGB_OFF);
ulpn.setDevice(DEVICE_LED_OFF | DEVICE_SENSORS_OFF | DEVICE_RF_OFF);
// Disable all CPU peripherals for low power
ulpn.disableCPUDevices();
// Enable A1 IRQ with pullup (I think both rising and falling will trigger IRQ)
ulpn.setSensorsIRQ(IRQ_SENSOR_A1_ENABLE , true);
// go to sleep mode, NO BOD, only push button and A1 can wake us
ulpn.sleepDeviceWake(SLEEP_BOD_OFF | SLEEP_WAKE_SWITCH, 0);
// We've been waked up by a IRQ, disable ours until we done the job
ulpn.setIRQ(IRQ_SWITCH_DISABLE);
// Disable A1 IRQ
ulpn.setSensorsIRQ(IRQ_SENSOR_A1_DISABLE);
That should works, don’t forget to add a callback with ulpn.attachSensorInterrupt(your_handler) for sensor IRQ (A1) if you need to detect witch irq waked the node
Use with caution with 1.3 all will change with dedicated TPL Wake pin connected to D3 (INT1), it’s just a dirty workaround
Take a look into the lib setSensorsIRQ() on how to do interrupt with PCCINT register, may be it’s also possible to add A2 in this routine to make things simpler.
If my memory serves well, there is somewhere in this thread a link to a library handling all interrupt types…
Edit: in the MiniLora thread
Correct t’s named as far as I remember PinChangeInterrupt
What an overhead of flash and memory use to drive 1 pin interrupt, when we have onboard LoRaWAN stack and when this INT could be managed only with a few lines of code 
The MCCI licensing is a complete mess…
They decided to re-license their code because upstream IBM did.
While I understand the intend, it is not really legal as by doing this they re-license code which has been contributed under another license agreement. This can only be done if all project contributors agree on this license change…