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.
Do you use this lib? I tried to replace my old one (https://github.com/things-nyc/arduino-lmic) 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 https://github.com/matthijskooijman/arduino-lmic). It also provides support for more regions/ISM band frequencies so your code can be used by more people around the globe.
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
platform = atmelavr
board = lora32u4II
framework = arduino
monitor_speed = 115200
MCCI LoRaWAN LMIC library
; *** 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 CFG_in866=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 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).
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.
@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.setDevice(DEVICE_LED_OFF | DEVICE_SENSORS_OFF | DEVICE_RF_OFF);
// Disable all CPU peripherals for low power
// 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
// Disable A1 IRQ
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.
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…