I dont want to sleep....

[grichfitz]

I am using the following code for the wireless stick, it seems to be the only workable example for uploading to the helium network.

It seems a bit over complex and must sleep. I want to do the following:

Join...
Loop updating the display with sensor data..
Every 10 mins
Send sensor data

But the following code, must sleep otherwise it doesnt work.

Does anyone have a better example?

void loop()
{

switch( deviceState ){
case DEVICE_STATE_INIT:
{
LoRaWAN.init(loraWanClass,loraWanRegion);
break;
}
case DEVICE_STATE_JOIN:
{
Display.clear();
Display.drawString(2, 0, "Joining...");
Display.display();
LoRaWAN.join();
break;
}
case DEVICE_STATE_SEND:
{
Display.clear();
Display.drawString(2, 0, "Sending...");
Display.display();
prepareTxFrame(appPort);
LoRaWAN.send(loraWanClass);
deviceState = DEVICE_STATE_CYCLE;
break;
}
case DEVICE_STATE_CYCLE:
{
// Schedule next packet transmission
txDutyCycleTime = appTxDutyCycle + randr( -APP_TX_DUTYCYCLE_RND, APP_TX_DUTYCYCLE_RND );
LoRaWAN.cycle(txDutyCycleTime);
deviceState = DEVICE_STATE_SLEEP;
break;
}
case DEVICE_STATE_SLEEP:
{
getData();
LoRaWAN.sleep(loraWanClass,debugLevel);
break;
}
default:
{
deviceState = DEVICE_STATE_INIT;
break;
}
}
}

[a9460620]

/LoraWan Class, Class A and Class C are supported/
DeviceClass_t loraWanClass = CLASS_A;
Change CLASS_C

[DiegoPinillaU]

/LoraWan Class, Class A and Class C are supported/ DeviceClass_t loraWanClass = CLASS_A; Change CLASS_C

Class C leaves the radio on for receiving. If I want to do some datalogging instead of sleeping after sending a packet, I would'n want the device to keep the radio on as it wastes battery life. Sadly I don't find any way of disabling this sleepy behavior in code.

[jcwren]

LoRaWAN.sleep() needs to be called periodically, as it updates some internal timers. Unfortunately, and for no logical reason, Heltec does not provide the source for Mcu.S, timer.S, or rtc-board.S.

If you call LoRaWAN.sleep() with CLASS_A as the parameter, it will put the system into deep sleep until the next wakeup time, which includes reconfiguring about 10 different GPIO pins to inputs before calling esp_deep_sleep_start() . It you call it with CLASS_C as the parameter, it will do its thing and return immediately. There's no evidence that it needs to be called absolutely every millisecond (and it would be absurd on their part to assume that it would be since so many Arduino programs use delay(), including a number of delay calls if you're using the OLED functionality).

The pins that are being configured as inputs are 4 (OLED_SDA), 5 (LoRa_SCK), 14 (LoRa_RST), 15 (OLED_SCL), 16 (OLED_RST), 17 (U2_TXD), 18 (LoRa_CS), 19 (LoRa_MISO), 26 (LoRa_DIO0), and 27 (LoRa_MOSI). For reasons unknown, they don't also set 35 (LoRa_DIO1) or 34 (LoRa_DIO2) to inputs (sure, they're already inputs, but so was LoRa_DIO0, so either do none or do all...)

It's not clear if you NEVER want to go into deep sleep yet still power down the radio, or if you want to do a few fata logging things before you do enter deep sleep. If you never want to go into deep sleep, you can write your own code to set the pins to inputs, and at some point or another have to basically re-run this code:

  SPI.begin (SCK, MISO,MOSI,SS);
  Mcu.init (SS, RST_LoRa, DIO0, DIO1, heltecLicense);
  deviceState = DEVICE_STATE_INIT;

or, create yourself a variable called something like okToDeepSleep and do something like this:

case DEVICE_STATE_SLEEP :
  LoRaWAN.sleep (okToDeepSleep ? CLASS_A : CLASS_C, LORAWAN_DEBUG_LEVEL);
  break;

Normally leave okToDeepSleep false until you're ready to deep sleep, then

okToDeepSleep = true;
deviceState = DEVICE_STATE_CYCLE;

(so it recalculates the wake-up time correctly), then it'll enter deep sleep and behave as normal class A sleeping. Remember to set okToDeepSleep = false; just after the Mcu.init() call or it may go back to sleep the next time it hits the DEVICE_STATE_SLEEP state.

[DiegoPinillaU]

LoRaWAN.sleep() needs to be called periodically, as it updates some internal timers. Unfortunately, and for no logical reason, Heltec does not provide the source for Mcu.S, timer.S, or rtc-board.S.

I agree with this, the only reason I find for this decision would be to enforce the use of the license number and prevent the user from bypassing this. Even if that's the case, I think there are better ways to achieve it.

It's not clear if you NEVER want to go into deep sleep yet still power down the radio, or if you want to do a few fata logging things before you do enter deep sleep. If you never want to go into deep sleep, you can write your own code to set the pins to inputs, and at some point or another have to basically re-run this code:

In this point I don't want my device to deepsleep at any point, as it would lose all info stored in RAM. I know I can store it in non volatile storage and then recover it but I want to avoid that, as it is slower and sketchy.

or, create yourself a variable called something like okToDeepSleep and do something like this:

case DEVICE_STATE_SLEEP :
  LoRaWAN.sleep (okToDeepSleep ? CLASS_A : CLASS_C, LORAWAN_DEBUG_LEVEL);
 break;

Normally leave okToDeepSleep false until you're ready to deep sleep, then

I've just set it to just CLASS_C and it seems to work fine, except for the active radio listening.

Something strange that I noted is that with CLASS_A you can cycle like 5 consecutive times without entering deepsleep (I've set the app duty cycle to 3000 ms), then it behaves as spected.