socket.send(msg) timeout

[chris]

Hi, does anyone know a reason why the send would give a:
OSError: [Errno 11] EAGAIN
for a LoRa socket? I don't believe its doing anything like waiting on a ack confirmation is it? I'm running with socket.setblocking(False) and a raw LoRa socket. I'm trying to send at 100msec intervals.

I've also seen where the a recv function will timeout when I know its missed several sends and only a moment before it was working.

I'm trying to send a a higher rate until the other device sends a response. Sort of a re-transmit until acknowledged scheme. My intent is to allow intermittent signal strength to be more responsive and usable.

Thanks,

Chris

[chris]

The send packet is 7 bytes long and the ack is 2 bytes. On the data rate I didn't set so whatever the default is.

Power consumption is a good point on how to tell if it's busy but I want a software method. If we could tie a specific exception type to this cause then I could do something special in the exception handler.

[bmarkus]

@chris said in socket.send(msg) timeout:

Is there any way to really see how long the radio is taking?

You can measure the power consumption of the board, best with an oscilloscope. You will see the increased consumption when transmitter is on.

[daniel]

@chris ok, then it's definitely not because of the duty cycle limitations. I'll investigate. What's the size of the packets that you are trying to send?

[chris]

This is on the 915MHz version and with LoRa RAW. I did slow things down and it technically worked but it's not too usable at those speeds. When I look at how long it takes to send a packet using time stamps around the socket send it's fast. Is there any way to really see how long the radio is taking? Also how come the send buffer can't take the new data and send it over to the radio when ready?

[daniel]

@chris if this is with the 868MHz version of the LoPy then you are experiencing the effect of duty cycle control. Transmitting every 100ms is just not possible in Europe. Besides that, sending a LoRaWAN packet (per protocol specs) takes more than 1 second because the device needs to wait for the first receive window (which occurs 1 second after the packet is sent).

Just to be clear, is this happening with LoRaWAN or raw LoRa. Which data rate are you using?

Cheers,
Daniel

[chris]

I did just upgrade to the latest firmware (1.3) and the problem is still there.