Hi All,
I’m wondering if anyone knows a way to abort an ongoing LoRa transmission? I use STM32L0 / SX1272 and I-CUBE-LRWAN.
I’m working on a super low power node and this feature would be necessary in case the power manager module panics about running out of energy.
Any hint or suggestion is appreciated.
Thanks,
-Tamás
Most of the LoRa MAC stacks don’t really cater for aborting a transmission, particularly as almost all the work is done by the Semtech chip once the MCU has passed over the message.
So you’d have to turn the radio off using hardware.
I’d not expect the battery level to drop that dramatically whilst you are queuing the message, so you could just not queue it or let it carry on. Ideally you reduce the frequency of transmissions well in advance.
In some respects, having a power manager is an extra burden. Just use a Lithium battery directly, no LDO and use the MCU to monitor battery level.
@descartes Thanks for your reply. Unfortunately, I don’t have the freedom of choice re the power management. It’s an energy harvesting thing, therefore a bit special. When you suggested radio off using hardware, what did you mean?
Some sort of super-cap is indicated as you are going to make a mess of your local airwaves if you keep pulling the plug on a transmission - and it is totally expected that you listen for downlinks if you manage a send.
By hardware, I mean a MOSFET, although toggling the reset pin would probably suffice.
I know, it’s not ideal. But the power mananger will shut the power down anyway, which means a reboot for the MCU. Cancelling the transmission might keep the MCU running and it could try transmitting later again.
Regarding the MOSFET, I’m using a LoRa module and I’m not sure it has anything like that on board. Not even sure about the reset pin of the radio. But it’s a good idea, I’ll ask the manufacturer!
Just out of curiousity, your previous comment about using the Lithium battery directly is an interesting one. I don’t understand how that works as battery voltage can go up to around 4V. I’m wondering if this method is explained somewhere in details? I don’t want to go too much off-topic here.
Thank you!
I’ve not seen any modules with a power switch on the board but almost all of them have some sort of reset.
“a Lithium battery” aka not necessarily a LiPo - in this case Energizer L91’s which are 1.7V at the start, have a very flat discharge profile and very low self-discharge. Many modules will work down to around 3V before it all gets messy. Shelf life is around 20 years.
If you have any sunshine, a small panel, this Adafruit module, a small Lipo and an LDO works nicely.
So one combo is to use the solar option with the Lithium batteries as backup if the LiPo gets too low.
What is your energy harvesting module? And who’s mandating it?
I would suspect that toggling the LoRa device reset pin or powering the LoRa device off wont work, unless you then re-do the entire device initialisation in software. The default register settings of the LoRa device are no good for LoRaWAN.
You set the operating mode of the LoRa device, Sleep, Standby, TX, RX with a register write. So you can stop TX or RX mode if you want. This is easy enough and can be done outside of the LoRa library you are using, you just need to know the NSS pin number.
I think the OP is hoping to stop a transmission in progress, would be interesting to know if that is possible via the registers in an academic sense.
I’d be going for a super-cap with enough charge to run a moderate sized transmission.
Its not just academic, its how the LoRa devices work, and yes you can stop a transmit in progress.
However whilst its easy to do, the consequences may not be so simple to deal with. If the transmit does not complete there will be no TXdone signal, so you would need to understand the consequences of that occuring.
To me it would make more sense to be sure there is enough power to deal with it.
Its a bit like when cars of old had a reserve fuel tank, which when you ran out of fuel, you could flip a lever in the car boot and have an ‘extra’ gallon of fuel. Pointless really, just keep an eye on the fuel gauge and fill up in time.
I totally agree, adding extra hardware could help a lot and a transmission shouldn’t be started unless there’s a fair chance to be able to finish it. In my case this is not an option, and in a way, that seems to lead to an interesing conversation. 
I have to work with an energy havesting power supply which is not on the market yet, and unfortunately I’m not allowed to share details about it.
@LoRaTracker I don’t know enough details about the internals of the SX1272. If you’ve done this before could you please give more hints about which registers to look at? I agree, it sounds like a more elegant solution than toggling the reset pin, but I would be concerned about writing registers behind the back of the LoRa stack. I would have to make sure that both the radio and the stack are in a consistent state. What do you think? I guess that requires deep knowledge of both.
Toggling reset and reinitalising the stack sounds more brutal but safer to me.
@descartes @LoRaTracker Thank you for your time to discuss. It’s very useful. 
In that respect, use ABP unless you can figure out the details of storing the OTAA session.
void writeRegister(uint8_t address, uint8_t value)
{
digitalWrite(NSS, LOW); //set NSS low
SPI.transfer(address | 0x80); //mask address for write
SPI.transfer(value); //write the byte
digitalWrite(NSS, HIGH); //set NSS high
}
Then a function call of;
writeRegister(0x01,0x81);
Will put the LoRa device in standby mode.
I have to work with an energy havesting power supply which is not on the market yet, and unfortunately I’m not allowed to share details about it.
If this is a commercial product, then I suggest you dont alter code unless you have a very good understanding of the possible consequences.
It’s going to have questionable value in the market place if you have to do random things like cutting off transmissions, something if I was asked to review I’d give a big thumbs down. 
Also (thinking of TTN V3) if that Tx was actually an acknowledgement/response to e.g. a downlink MAC command from the NS that was just cut off of course and never actioned the (TTN) NS would likley continue to send such downlink commands to the now deaf/inactive node having a detrimental impact on the network…not a good idea! I’m with Nick - tell the developer of this new unit its not a good plan and have another thumbs down 
, better they/you allow for a smalll reserve - perhaps using a super cap as suggested by Nick, to atleast allow the tx/rx/command cycle to complete before you then shut down gracefully… 
@descartes @LoRaTracker @Jeff-UK Thank you all for the invaluable feedback! I totally agree with your point of view.
You can readily calculate the time and thus energy needed for a transmission before actually doing it. The duration code is already there in a typical stack.
I’m not sure if aborting a transmission via SPI command would actually do so, but many LoRaWan implementations all but completely reconfigure the radio at each use anyway, so a few more operations to do so with actual completeness after resetting it wouldn’t be a big deal either.
If you decide to just do it and risk things browning out, then with either ABP or OTAA there is state you need to save first, either in RAM in an independent power domain backed by a coin cell, or in something with a high write life - maybe fram or mrem if there’s something exotic which has high write life and low write current.