search

lloydroc / ebyte-sx1276

EByte E32 for the Raspberry Pi on Linux
Apache License 2.0
20 stars 5 forks source link

Failed to escape IDLE during TX #31

Open viaSeunghyun opened 11 months ago

viaSeunghyun commented 11 months ago

Hello,

I've taken your advice and written the code to only do TX to check for some symptoms. (i.e. changed it to one-way communication for testing)

The problem is that e32.service fails to return from IDLE after the following sequence.

In e32.c, After L960 -> L972 -> L1001 -> L1131 -> L1197, 

Oct 17 13:34:28 raspberrypi e32[26532]: e32_poll_input_enable
Oct 17 13:34:28 raspberrypi e32[26532]: e32_poll_socket_unix_data: received 18 bytes from unix domain socket: /home/pi/e32.tx.data
Oct 17 13:34:28 raspberrypi e32[26532]: e32_transmit: transmitted 18 bytes
Oct 17 13:34:28 raspberrypi e32[26532]: e32_poll_input_disable
Oct 17 13:34:28 raspberrypi e32[26532]: e32_poll_gpio_aux: transition from IDLE to TX state
Oct 17 13:34:28 raspberrypi e32[26532]: e32_poll_input_disable

It seems to be blocking after entering e32_poll_input_disable.

One of the possible causes is that my code is Non-Blocking. So, I am not getting any results with recvfrom(10) after sendto. This is because if I changed socket.socket to Non-Blocking to handle timeout exceptions, recvfrom will throw an exception along with it, and it will not recover unless my main process is restarted.(This is something I'm still working on the cause of :( )

The other possible cause is that there is a mismatch between the State Machine logic in e32.c and my actual usage.

I'm bind() one socket, and I'm only doing TX, but the problem is that e32 is blocking.

The logs are as follows, and the workaround is to initialize e32.service from scratch, and packets are being sent out normally again.

At this point, the driver is showing symptoms of a significant amount of data accumulating in the buffer. Dozens of pieces of data are exposed at the same time, with all the bits being identical. Even if I stop my code, it is still sending something based on my packet structure. To stop the buffering, don't restart e32.service, stop it completely and then start it, this will fix it.

It looks like I may need to intervene in the control itself, rather than just a buffer for sending data, for clear control.

viaSeunghyun commented 11 months ago

Cleared while creating the issue.

The issue is resolved by forcing a minimum delay time for LoRa dispatch. By any chance, is there any way to know the status of e32.service, such as if it is waiting for a transmission by buffering?