ESP32 Problems

(LoRaTracker) #25

At those parameters, time on air for an 12 byte packet would be around 40mS.

You also appear to be using a point to point LoRa library, and this being a TTN forum readers might not have much experience of that library, why would they really.

(Ud Lo Ra) #26

it seems just pure LoRa, no receive windows. However, I do not know whether opening and closing communication is lasting nothing.

(Maedman) #27

Can you explain it some more? I dont know what you trying to say here.

Where did you calculate this? I used a excel sheet available here in the forum for the 17ms.

You are right, I wanted to start with the point to point. If this is running (and I get the power consuption and number of transmissions down :slight_smile: ) I will do the next step and try to unse TTN :slight_smile:

(LoRaTracker) #28

The Semtech LoRaCalculator Tool.

(Amedee) #29

For LoRaWan Class A, downlinks are only sent after uplinks. After sending, a node need to listen to see if there is a downlink packet sent. This happens during the RX1 or RX2 window (depending on the frequency plan / channel).
So it would make sense to me to wait for the receive window is over before going to sleep…

(Amedee) #30

Oh – wrong forum then…

(Maedman) #31

Ah - thank you. I forgot about this. How can I calculate the time of this window or is it not possible?

I just want to start with pure LoRa. I thought it would be easier to begin with.

(Amedee) #32

With OTAA, RX1 is 1 sec, and RX2 one second later, the choice of the window is based on the frequency plan.
But again this is LoRaWan specific.

(Maedman) #33

Okay, got it. Thank you.
Is it possible, that the LoRa module is by standard in the LoRaWAN Class A? So the chip is thinking, that its sending to a network? Cant figure it out why these times are not the same or even in the same area… but the 700ms is to huge!

(Maedman) #34

I dont have access to the Semtech LoRa Forum and to the tools. I calculted with some more free calculators for LoRa and returning me the ~17ms is correct…

(LoRaTracker) #35

You can download the LoRaCalculator from the Semtech Website.

(LoRaTracker) #36

No, your missunderstanding the difference between what your trying to configure, point to point LoRa, and LoRaWAN.

Tell a LoRa device to send a packet and it does just that, and that only, it sends a packet. When its finished sending the packet it turns the transmitter off. It does not attempt any clever stuff like listening for replies. If you want to listen for a reply (like you might in LoRaWAN) you have to specifically configure the LoRa device to flip to being a receiver.

If you think the LoRa device is transmitting longer than you think it should be, you might want to raise the issue with the author of the library you are using.

(Arinze Izukanne) #37

Hi,

As an aside, i notice you are using pins 34 and 35 as RX and TX. Note that those pins are input only. While it works now for an RX only operation, the TX on Pin 35 will never work should you try to transmit out of Serial2.

(Maedman) #38

Thank you again for your explanation. I was just looking for a reason of the behavoir of the board - thats why i made the “default mode suggestion”.
I will try to contact the author of the library I am using with this issue, thats a good idea.

(Maedman) #39

Thank you for that hint! This connection is only to get the data from the electrical meter to the board, there is no communication from the board to the electrical meter. :slight_smile:

(Vtomanov) #40

Use ESP32 ULP - with one analog measurement every 200msec will last 10 years on a battery

https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/ulp.html

here is for arduino UI/comparability mode:

(Maedman) #41

Thank you for that hint, its looking very complicated tbh but I will try to implement it! If I have success I will let you know about the effects :slight_smile:

(Maedman) #46

I tried to print the millis and thats what its printing:

    Serial.println(millis());
        LoRa.begin(BAND, PABOOST);  // Sending via Lora start
        Serial.println(millis());
        LoRa.beginPacket();
        Serial.println(millis());
        LoRa.print(trans[1]);
        Serial.println(millis());
        LoRa.print(trans[2])
        Serial.println(millis());
        LoRa.endPacket();
       Serial.println(millis());

1215
1285
1285
1286
1286
1946

So I would say, that the LoRa.begin and LoRa.endPacket is the problem --> libary probelm
Am I right with this?

Best regards

(Sshanks) #50

hmmm I watched about this in “The guy with the swiss accent” video and give it a try and it worked for me - I’m using Heltec LoRa32 Arduino IDE 1.8.8

(tlu) #53

Have you tried any other SF values to see whether the duration increases even further?