Problems since 0.0.5 - ABP and non-Sleeping

#1

Hey @Aaron

I’m seeing two issues since changing to the current github version (0.6 AT, etc) from ~0.0.4 on my dev board.

  1. ABP doesn’t seem to be working. The keys are correct in the startup messages, the debug messages says it’s sending, but the gateway never gets anything. Reverting the code to my 0.0.4 version works fine – it’s not a hardware issue. Changing to OTAA gets (at least) the join messages being sent, I didn’t have valid keys for beyond that at the time.

I reverted to using @wasn 's GPS example (/w LoRaWAN) and the correct keys, and still nothing on ABP. Weird. Does it work for you?

  1. LoRaWAN.sleep() isn’t optional anymore. TX Timeout occurs if it’s not called, but I don’t want to sleep when I’m using softSerial. This is a change from 0.0.4 at least, was it intentional?

Thanks,
Bruce

#2

Thank you for your info. I will look into this now.

#3

Hi @bwooce

I tested the ABP mode just now. It working well at my side. Did you clear the Frame counter in your server when the ABP mode begin?

image
image.png896×923 136 KB

Sorry for my poor English, I’m not very clear what this mean.:sweat_smile: We didn’t fix any thing with the LoRaWAN.sleep()

#4

Abp is working here without problems

#5

Thanks to you both. Must be a local issue then, thanks for the confirmation on that. The packet doesn’t even get heard by the GW so it’s not a frame count issue. And reset it too :slight_smile:

@Supporter The sleep issue I’m seeing is that if you take the LoRaWAN example and comment out the sleep() then the .send()s will fail with a TX timeout. It didn’t used to do this.

I don’t want to sleep in this case because there are sensors to monitor and power saving isn’t an issue.

(I guess if ABP isn’t working properly I should suspect the whole setup, but I’d be thankful if you can give it a try)

#6

if i understand it right the sleep is needed for the timing.
without the sleep i get the problem that the node sends without waiting the dutycycle time

#7

If your system don’t need sleep, why not choose Class C?

#8

To bypass the sleep function, change this in your loop:
case DEVICE_STATE_SLEEP:
{
if (powersave) {
digitalWrite(Vext, HIGH);
LoRaWAN.sleep();
} else {
digitalWrite(Vext, LOW); //Stay alive
Radio.IrqProcess( );
}
break;

By setting the variable powersave you can choose to sleep or not.

Edit: In my case I have a weather station with solar power. So when there is enough power I want it to do constant measurements of the wind speed. When it gets low on power it goes into a powersave mode.

1 Like
#9

I just want know how I can use class C without sleep.

#10

In the CLASS C mode, sleep is disabled by default. Just nee select CLASS_C in the tools menu:

image
image.jpg1156×984 280 KB

#11

@Supporter
Can you show some code example. I try to use class c but never join.
Maybe the state machine must to be different.

#12

Just checking, you are calling

in the state DEVICE_STATE_SLEEP? I’d assume that’s required as you don’t want to sleep, but I agree an example of Class C operation would be great. TTN doesn’t support Class C yet, so I can’t build (test) one myself.

#13

Yes, the function LoRaWAN.sleep() contains the Radio.IrqProcess( ) call. So if you bypass the sleep function, you need to call Radio.IrqProcess( ) in your own process to keep the radio working. This however is only required if you are sending data and not using the sleep function at all. The better option in this case would still be to use the CLASS C setting. I eventually stepped away from this method and are using a different approach by adjusting the sleep time to a minimum and keep the process in the DEVICE_STATE_SEND loop for the time needed.

if ((TimerGetCurrentTime() - readmillis) > appReadCycle ) { //appReadCycle will be the time spent awake
         getSensordata(); //get your data that were collected
          prepareTxFrame( appPort );
          LoRaWAN.send();
          deviceState = DEVICE_STATE_CYCLE;
}

//readmillis will be resetted to TimerGetCurrentTime() when the device has woken up.

This way I can dynamically adjust the sleep and working time according to the available battery power.

Edit: typo. This method works with TTN. I guess you could trim the sleep time down to 1 millisecond if really needed. Eventually due to the fair use policy, the station will sleep for about 4 minutes, collect data for 1 minute and send it and sleep again.

1 Like
#14

The main difference between class C and Class A is the receiving window. In CubeCell’s Class C mode, the SX1262 will not sleep, and is always in listening mode, while the PSoC core will sleep. When the SX1262 receives the downlink, it will wake up the MCU.

1 Like
#15

The code is the same, Class A and C are switched by the options on the menu, you can understand it as a macro definition.