ESP32 Problems

[LoRaTracker]

@Maedman

Yes, I am sending only the relevant information every 4 secounds at the moment. Due to the small data size I calculated, that there should be no problem with regulations in germany or even TTN Fair access policy

Can you clarify ?

Your suggesting your intending to send these 2 integer packets every 4 seconds over TTN ?
Can you clarify the confusion ?

[UdLoRa]

@Jeff-UK I agree, it was just a sort of indirect reminder to @Maedman that his reasoning is not within LoRaWAN but outside. Le me add other info and summarize:

• sending 12 bytes every 4 seconds at SF/500 might be within LoRa rules, even if LoRa is not made for this, but:
• SF7 500KHz is not among EU channels for LoRaWAN. You have to switch to SF7125, which is four times slower, so 4,38ms becomes at least 17ms, and is still not sufficient because:
• “there are no security aspects in sending yet”: yes, but for this and other, LoRaWAN adds a 13 bytes header, so 12 bytes of payload become a 25 bytes packet (of which, 4 are not needed because just separators… you already know where the integers are by position).

[Maedman]

@LoRaTracker @Jeff-UK @UdLoRa

Thank you all for your answers!

@UdLoRa

sending 12 bytes every 4 seconds at SF/500 might be within LoRa rules, even if LoRa is not made for this,

That was just an theoretical calculation. At that time, I was not aware that also the number of transmissions are regulated at TTN, thats now my biggest problem

@UdLoRa

SF7 500KHz is not among EU channels for LoRaWAN. You have to switch to SF7125

thank you for that hint! I will check again the regulation!

@UdLoRa

“there are no security aspects in sending yet”: […] so 12 bytes of payload become a 25 bytes packet

You are right, I dont need the seperators in the end. I will recalculate it and change my code to SF7 125kHz. Lets see if I can stay into the borders of EU regulation “Worst” case for me would be to set up an own Gateway.

[Maedman]

Okay, besides the talk about the frequency of sending my data, the problem with the ESP32 Board is still not solved. I measured again, because I found out, that I forgot to measure with the oszi against ground… it is looking like this now:

The time with the voltage of 198.01mV over 720ms is representing the time the LoRa module is on. Why is this not equal to the time on air/sending time? I am only switching it on for sending and turning it of after it.

[LoRaTracker]

@Maedman

Why is this not equal to the time on air/sending time? I am only switching it on for sending and turning it of after it.

How do you know its is not ?

What does the TTN console say about the received packet time ?

[Maedman]

@LoRaTracker

Why is this not equal to the time on air/sending time? I am only switching it on for sending and turning it of after it.

How do you know its is not ?

“Bitrate” R_bit=SF* BW/2^SF *CR
"BW=125 kHz,SF=7,CR= 4/5
R_bit=5468,75Bits/s
"Bytes to transmit (only data)=12=96 Bits
(96 Bits)/(5468,75 Bits/s)=17,55 ms
Time to transmit the data would be 17,55 ms and the Board is on high power for over 700ms, even I am only sending which these 4 lines:

@Maedman

`LoRa.beginPacket(); 
LoRa.print("$"); LoRa.print(trans[1]); LoRa.println("$");
LoRa.print("&"); LoRa.print(trans[2]); LoRa.println("&"); 
LoRa.endPacket();`

“Packet transmission time = Packet size / Bit rate”

[UdLoRa]

Add a Serial.println(millis()) before and after the transmission code.

[Amedee]

@Maedman

Why is this not equal to the time on air/sending time?

Probably because it needs to wait for rx1/rx2…

[LoRaTracker]

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.

[UdLoRa]

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

[Maedman]

@Amedee

Probably because it needs to wait for rx1/rx2…

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

@LoRaTracker

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

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

@LoRaTracker

You also appear to be using a point to point LoRa library

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 ) I will do the next step and try to unse TTN

[LoRaTracker]

@Maedman

Where did you calculate this?

The Semtech LoRaCalculator Tool.

[Amedee]

@Maedman

Probably because it needs to wait for rx1/rx2…

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

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]

@UdLoRa

it seems just pure LoRa, no receive windows.

Oh – wrong forum then…

[Maedman]

@Amedee

For LoRaWan Class A, downlinks are only sent after uplinks.

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

@Amedee

it seems just pure LoRa, no receive windows.

Oh – wrong forum then…

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

[Amedee]

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]

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]

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]

@Maedman

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…

You can download the LoRaCalculator from the Semtech Website.

[LoRaTracker]

@Maedman

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!

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.