lloydroc / ebyte-sx1276 Goto Github PK

View Code? Open in Web Editor NEW

20.0 20.0 5.0 162 KB

EByte E32 for the Raspberry Pi on Linux

License: Apache License 2.0

Makefile 0.78% Shell 0.05% M4 2.27% C 83.57% Python 12.77% Dockerfile 0.56%

ebyte-sx1276's People

Contributors

Stargazers

Watchers

Forkers

flxkid thegeek82000 hedgu4 oksigenasu alkexan

ebyte-sx1276's Issues

Error getting e32 module status.

First of all I want to say that I am a beginner. Many things are new to me, especially GitHub. So I apologize if I don't respect the codes of the community.
It seems to me that this is where we ask for help when we have a problem.
So, I have a problem that I can't find the source of. I use a raspberry pi 4 with Raspberry PI OS (64-bit) flasher on an sd card with Raspberry Pi Imager.I disabled bluetooth by adding at the bottom of the file "dtoverlay=disable-bt" using the command "sudo nano /boot/config.txt", and running "sudo systemctl disable hciuart".
Then activate serial-port with the command "sudo raspi-config" execute in $. (under Option/ Serial Port interface, serial login shell is disabled and serial interface is disabled).After that I plug in the e32 module as shown, then run the commands to install e32 software. But for some reason when I do "e32 -s"
i get:
"ERROR [ENOENT No such file or directory] timed out

unable to read version
".

Thank you to those who will take the time to answer me.

error reading from stdin

suddenly I faced with

e32_poll_gpio_aux: received 1 bytes for a total of 28 bytes from uart
�>>���>>�>>>���p�o�����e32_poll_input_enable
e32_poll_gpio_aux: transition from IDLE to RX state
e32_poll_input_disable
ERROR [EBADF Bad file descriptor] error reading from stdin

after using version 1.10.0.

I'm running it in a PI 4 this time.
Any clue on this issue?

Create Debian Package

To install we currently have to download the tarbal and install from source:

./configure
make
sudo make install

If we create a .deb package the installation instruction is

apt install e32 # not sure of name

Would be much preferred to the installation from source.

Q: Difference between e32.tx.data and e32.rx.data

Hello?
It's been a while.

I've been using E32 well, with your code making it easy.
I'm logging an issue because there's an implementation I'm using that doesn't make sense to me personally, and I'd like to ask @lloydroc a question.

See the code for the E32TX and E32RX.
In e32tx, we create a socket for e32.tx.data, e32rx creates a socket on e32.rx.data.

However, in reality, only the names are different and all channels (RD&WR) are bound to /run/e32.data.
If these two sockets are connected to a program at the same time, both e32.service and the user script will block indefinitely (socket.timeout if set to Non-Blocking).

Oct 12 22:25:18 raspberrypi e32[15843]: e32_poll_input_enable
Oct 12 22:25:19 raspberrypi e32[15843]: e32_poll_gpio_aux: transition from IDLE to RX state
Oct 12 22:25:19 raspberrypi e32[15843]: e32_poll_input_disable
Oct 12 22:25:19 raspberrypi e32[15843]: e32_poll_uart: received 16 bytes for a total of 16 bytes from uart
Oct 12 22:25:19 raspberrypi e32[15843]: e32_poll_gpio_aux: transition from RX to IDLE state
Oct 12 22:25:19 raspberrypi e32[15843]: e32_poll_gpio_aux: additional sleep for uart buffered data
Oct 12 22:25:19 raspberrypi e32[15843]: e32_poll_gpio_aux: received 2 bytes for a total of 18 bytes from uart
Oct 12 22:25:19 raspberrypi e32[15843]: e32_write_output: sending 18 bytes to socket /home/pi/e32.rx.data
Oct 12 22:25:19 raspberrypi e32[15843]: e32_write_output: sending 18 bytes to socket /home/pi/e32.tx.data

<= This Point Blocking all Sockets and Channels. No Logging in journalctl. E32 Service and All Client is blocked.
<= And when kill client process, E32 Service unblocked

Oct 12 22:27:56 raspberrypi e32[15843]: e32_poll_input_enable
Oct 12 22:27:56 raspberrypi e32[15843]: e32_poll_uart: received 512 bytes for a total of 530 bytes from uart
Oct 12 22:27:56 raspberrypi e32[15843]: e32_poll_socket_unix_data: received 0 bytes from unix domain socket: /home/pi/e32.rx.data
Oct 12 22:30:43 raspberrypi e32[15843]: ERROR [?UNKNOWN? Connection refused] e32_poll_socket_unix_data: unable to send back status to unix socket
Oct 12 22:30:43 raspberrypi e32[15843]: e32_poll_uart: received 408 bytes for a total of 938 bytes from uart
Oct 12 22:30:43 raspberrypi e32[15843]: e32_poll_uart: received 8 bytes for a total of 946 bytes from uart
Oct 12 22:30:43 raspberrypi e32[15843]: e32_poll_uart: received 1 bytes for a total of 947 bytes from uart
Oct 12 22:30:43 raspberrypi e32[15843]: e32_poll_uart: received 1 bytes for a total of 948 bytes from uart
Oct 12 22:30:43 raspberrypi e32[15843]: e32_poll_uart: received 1 bytes for a total of 949 bytes from uart
Oct 12 22:30:43 raspberrypi e32[15843]: e32_poll_uart: received 1 bytes for a total of 950 bytes from uart
Oct 12 22:30:43 raspberrypi e32[15843]: e32_poll_uart: received 1 bytes for a total of 951 bytes from uart
Oct 12 22:30:43 raspberrypi e32[15843]: e32_poll_uart: received 1 bytes for a total of 952 bytes from uart

<= The number of repetitive errors below is proportional to the client's break time.

Oct 12 22:30:43 raspberrypi e32[15843]: ERROR [EFAULT Bad address] e32_poll_uart error reading from uart, fd=8, buf=0x556332cc48, total=0x7feb388968, mode=0
Oct 12 22:30:43 raspberrypi e32[15843]: ERROR [EFAULT Bad address] e32_poll_uart error reading from uart, fd=8, buf=0x556332cc48, total=0x7feb388968, mode=0
......
......
......
Oct 12 22:30:44 raspberrypi e32[15843]: e32_poll_gpio_aux: transition from IDLE to RX state
Oct 12 22:30:44 raspberrypi e32[15843]: e32_poll_input_disable
Oct 12 22:30:44 raspberrypi e32[15843]: e32_poll_uart: received 16 bytes for a total of 16 bytes from uart
Oct 12 22:30:44 raspberrypi e32[15843]: e32_poll_gpio_aux: transition from RX to IDLE state
Oct 12 22:30:44 raspberrypi e32[15843]: e32_poll_gpio_aux: additional sleep for uart buffered data
Oct 12 22:30:44 raspberrypi e32[15843]: e32_poll_gpio_aux: received 2 bytes for a total of 18 bytes from uart
Oct 12 22:30:44 raspberrypi e32[15843]: e32_write_output: sending 18 bytes to socket /home/pi/e32.rx.data
Oct 12 22:30:44 raspberrypi e32[15843]: ERROR [?UNKNOWN? Connection refused] e32_write_output: unable to send back status to unix socket. removing from list.
Oct 12 22:30:44 raspberrypi e32[15843]: e32_poll_gpio_aux: error writing outputs after RX to IDLE transition

Is this what you intended, or is there a separate method that is valid?

Missing bytes in the socket

Hello,

I'm facing missing bytes in the socket created by the library

Nov 19 09:52:50 raspberrypi e32[745]: e32_poll_gpio_aux: transition from IDLE to RX state
Nov 19 09:52:50 raspberrypi e32[745]: e32_poll_input_disable
Nov 19 09:52:50 raspberrypi e32[745]: e32_poll_uart: received 8 bytes for a total of 8 bytes from uart
Nov 19 09:52:50 raspberrypi e32[745]: e32_poll_uart: received 8 bytes for a total of 16 bytes from uart
Nov 19 09:52:50 raspberrypi e32[745]: e32_poll_gpio_aux: transition from RX to IDLE state
Nov 19 09:52:50 raspberrypi e32[745]: e32_poll_gpio_aux: received 0 bytes for a total of 16 bytes from uart
Nov 19 09:52:50 raspberrypi e32[745]: e32_write_output: sending 16 bytes to socket /home/pi/e32.rx.data
Nov 19 09:52:50 raspberrypi e32[745]: e32_poll_input_enable
Nov 19 09:52:50 raspberrypi e32[745]: e32_poll_uart: received 1 bytes for a total of 17 bytes from uart

As we can see above in the logs, 17 bytes were received but only 16 were sent to the socket.

Not restored after entering IDLE during TX

          @viaSeunghyun with the implementation the sockets are unidirectional. On one end of the socket is opened for sending, the other for receiving. The socket `/run/e32.data` is waiting - `recvfrom` for clients to `sendto` it. In this case the socket `/run/e32.rx.data` which the `e32rx` program has bound is waiting for the `e32` program to `sendto`. This is because `e32rx` has registered the `/run/e32.rx.data` socket. When the `e32` receives data it will loop through all registered sockets and `sendto` data with the source as the `/run/e32.data` socket.

The problem we have here - at least I think - is that the e32tx has registered the socket /run/e32.tx.data for acknowledging transmissions but it's not listening on the socket after transmissions. Since the /run/e32.tx.data socket is registered when the e32 receives data it will try to send the data that it receives to it. But the e32tx program isn't recvfrom on this socket so the e32 program is blocked waiting to send the datagram. This is why I mentioned we should 1) not register /run/e32.tx.data or 2) we should recvfrom it. This would involve asynchronous I/O like using the poll system call. This is why 1 makes more sense. Because the Unix domain sockets are connectionless the /run/e32.tx.data serves a second purpose. That is when the client sends something to the e32 socket of /run/e32.data it can write back to that socket to acknowledge it was sent. It is this dual purpose nature that is confusing and be changed.

Regardless, this problem you have found is addressed, a change could be implemented to at least timeout when the e32 does a loop through the registered sockets and timeout if it cannot sendto a registered socket.

When writing, the clients if they have both tx and rx clients then it needs a way to be able to recvfrom all the registered sockets in any order. If the client has two sockets it cannot be blocked waiting recvfrom on socket 1 when socket 2 has data. This makes the implementation of clients challenging. Hence, the poll system call. Again, in this case the client realistically should only have a single socket open for receiving and not two. Since here the e32tx socket is intended to be for acknowledgement and not for receiving data. Also, it was intended to run and close the socket and not be in a loop.

The code looks quite good. However, in this section:

        try:
            (msg, address) = self.client_sock_rx.recvfrom(59)
            print(f"received from {address} {len(msg)} bytes with {msg}")

            self.rx_buffer += msg

            # to not block we would have to self.client_sock_tx.recvfrom()

        except BlockingIOError:
            # print(f"no received this time")
            pass
        pass

The e32 is also sending data to self.client_sock_tx since it was registered. If you were to recvfrom it after you recvfrom the rx it would work. But as mentioned this is pointless.

Thus, could you remove the following section so that received data will not be sent to

        if debug:
            print(f"Registering Socket {self.client_sock_tx_path} to {self.driver_sock_path}")

        self.client_sock_tx.sendto(b'', self.driver_sock_path)
        (msg, address) = self.client_sock_tx.recvfrom(10)

        if len(msg) != 1 or msg[0] != 0:
            print("Unable to Register TX Client")
            raise LoRa.Ebyte_Exception.DriverConnectionError
        else:
            if debug:
                print("TX Client Registered")

This way there is no registered socket for the transmitting side.

Again, the problem here is that the /run/e32.tx.data socket is registered for both TX acknowledgement and receiving data. Since the tx socket it's not being listened on it is blocking the e32 program. I need some time to think about the best path forward here.

Originally posted by @lloydroc in #29 (comment)

Wrong Frequency

Hi,

When we run the command e32 --status, e32 returns some properties, but the information about Frequency is incorrect.
My model is a 900MHz band model, but it shows up as 433MHz. It should actually show 868 MHz. The raw settings HEX is as follows.

0xc000001a1744

Command e32 --status dosn`t give feedback (stuck)

We are following this guide here : https://lloydrochester.com/post/hardware/ebyte-e32-lora-configuration-wiring/ same wiring:

Problem:

The command e32 --status hangs forever without output or feedback.

Raspberry Pi Command Terminal (e32 --status command):

Lora E32 Wiring :

Raspberry Pi 4 Wiring:

TTy port verification (ls -l /dev/ttyAMA0):

Any help will be appreciated !

We have a school project and we must use this setup , also we can't do anything further because we don`t know if the problem has something to do with the wiring or the e32 module

Failed to escape IDLE during TX

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.

ERROR [?UNKNOWN? Success] timed out

Observed Error Rate when Sending Files

Sending a file from one e32 to another the received file seems to always be missing bytes at multiples of the E32_TX_BUF_BYTES=58. I'm not truly convinced it's always multiples of 58 but it seems that way. I have a couple of counter examples. Swagging about 99.7% of the data arrives so the error rate is not that bad. This is with version 1.7. I have a decent antenna and the two are about 50ft away in a single family house where one is on the main floor and the other in the basement. One is on a Pi4 and the other on a Pi3.

Scenario

Transmit a file from one and receive on the other then compare the received file to the transmitted file.

Settings

e32 -s
Version Raw Value:        0x00000000
Frequency:                0 MHz
Version:                  0
Features:                 0x00
Settings Raw Value:       0xc000011a1744
Power Down Save:          Save parameters on power down
Address:                  0x0001
Parity:                   8N1
UART Baud Rate:           9600 bps
Air Data Rate:            2400 bps
Channel:                  23
Frequency                 433 MHz
Transmission Mode:        Fixed
IO Drive:                 TXD and AUX push-pull output, RXD pull-up input
Wireless Wakeup Time:     250 ms
Forward Error Correction: on
TX Power:                 30 dBm

Transmit Side

e32 --in-file random4.txt #transmit a file

Receive Side

e32 --out-file random4.txt.rx

File

The file contains random characters ending with newlines. There are 58 total characters - including the newline. It looks like this:

$ head -n 4 random4.txt
xgrJHpAmjvcBktdguAmqlihDwkwdBpjcwsDhHqlcDnv.yr.eJkngluKHw
kKbzfehqzgjHrepwzohIedEhiKsCydlI.muKitmAAotJkIsBbrw.mmKva
gbzjetajF.rlbJDhhqrHAfAdtyiFmDxtEiCJuDKdsfglbJtieCbEHuIee
IBqxlBftqGF.CJhIbsJD.JHsCxlijqeddnsgaysiij..KexExktmfeEzt
$  stat random4.txt
  File: random4.txt
  Size: 580000    	Blocks: 1136       IO Block: 4096   regular file
Device: b302h/45826d	Inode: 2223        Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/      pi)   Gid: ( 1000/      pi)
Access: 2021-06-29 11:24:45.651370358 -0600
Modify: 2021-06-29 11:24:45.711369777 -0600
Change: 2021-06-29 11:24:45.711369777 -0600
 Birth: -
$ wc -l random4.txt
10000 random4.txt

Comparison Results

When I look at the difference we see the following:

$ ls -l random4.txt*
-rw-r--r-- 1 pi pi 580000 Jun 29 11:24 random4.txt
-rw-r--r-- 1 pi pi 578433 Jun 29 16:01 random4.txt.rx

File random4.txt

$ diff random4.txt random4.txt.rx
21d20
< hGGjwClcoh.qxrhGn.wfn.qsvHgIuHfCzED.sacy.abwkagxDuCds.nFE
681d679
< BaddinHBtDIdyxGFrbamzmqDjwvrl.tE.wH.Bsyh.lcxIAplthpetGADo
1899d1896
< .dyj.dJniqlmebytdsneFrF.wwlfjfkiaAr.DnmEvpIsqs.lDkqmBhlcv
2393d2389
< ExGJIfdn.CtFze.JJHlu.vmytEtxcteyI.tCIpHFJeouinpJgAp.auwtk
2700d2695
< joIdBGHHlonJ.thwnjwfDzIzc.kmKzffF.asxHdAaio.tvwGwe.mvyDpx
2879d2873
< GdcFCdDnEsA.bjFzzdI.g.aywbpGFIKp.FhrICxqgjoik.zBGls.bkpxl
3283d3276
< sACdAjFt.naiJ.GHqAhIb.r.JgyxntoxgJsyejJJoJekHKdbocJpbfmCl
3369d3361
< rqCdsrAkqDA.FEDbAKkpKabvvfmheIvwljzvtdxJGbIxFxqjttzhtsDGp
3730d3721
< tafGm.xFrc.wgdtBwodD.fiCHtdaEBpjBvHFlqoClnkrqvK.J.uzKCoEh
3865d3855
< ipbuatBjBEpAqHyethGBCEHzyxhaAIJIbCociIdBqsoGm..F.vsrlddBs
3993d3982
< eml.q.qbuAbcefoEtdrfEaqtIgoHcvbgHfebemJq.KtJHHAfCJcsBsDwy
4051d4039
< .GxczznpFkhKcq.FE.tbndIv.mJhe.oJwD.hodo.nwHhEF.mvkoInahee
4116d4103
< EjE.cfKxcGdKqGlKzyBE.AzhpmB.leIInqyhwvEynImDAxAdafzEFd..p
4149d4135
< akdsGyGkmzCxi.JfzGiecEwxszuDEtcwD.annGxAkljsaKyADGwFoegzv
4296d4281
< EuheiFxoFEFmxtkzKoGrDGcrfzwffEEJc.GlDprm.arutB.qIwzxoBHtm
4666d4650
< BnevvClmm.cCGo.CKBn.bBBr.pfzwpIbu.oHAzgEwikpojdcKjbDCvgAC
4806d4789
< AfJ.aCnzebum.ddoxEyqvK.aKFkCv..hJIeKojvkcHwcDriehGuCulvqI
5756d5738
< K.hBg.ynv.EBukfzCuIx.GrwvfqaxhymfG.dwpqdf.xsjCdDa.mEEwfet
5928d5909
< DqhdjCyomHitsujwIzikxIKwaylurG..i.IrAsxFlykEemeE.ebn..BEn
6092d6072
< sJnDfw.HusxeCoq.mlAfv.fBf..ebHhlunGAJEtpaJlCbCznFeseIpF.h
6484d6463
< w.yDhw.FvqhxeGazGEKfmujGIc.GBEyktbFAxCr.KquGiusHkg.os.gfb
6529d6507
< nKkEKkHrjq.cHBfdasjJ.shbIlwxsyIFu.wihhAqqxsjdqmdIo.FG.yAj
7339d7316
< DBbrIhGunE.eJwketJtxDrGiI.IEmArcnll.kKtxAitnEwjjruy..i.G.
7528d7504
< .q.BAHdbyaafgq.goHxjokyqo.jIDC.CeDqxoly.lqKjHHh.sFjGHziho
7534d7509
< kf.DqgcuquCHirJpthtknhcHmwjKEK.abKDjIGvcejKnsFu.EGad.dCdr
7620d7594
< .fBGyCCosnuBguHb.jtbbpCzrCg.pCwhHc.sEuyjzeKFqvyhEdbFtviCj
7829d7802
< qn.ibc.EwegJKcJrFhqrqHwnDhEydirtnoBgjqDFmJsbEgsnnAEvumAjt
9878c9851
< CBnEGfnDHyApIcjhIqcAJCtqChwzBvjhao.GllneBatvcuDCCxoqdHGxG
---
> BnEGfnDHyApIcjhIqcAJCtqChwzBvjhao.GllneBatvcuDCCxoqdHGxG

File random3.txt

Same idea as random4.txt. It is missing 116 bytes which is 58*2.

$ ls -l random3.txt*
-rw-r--r-- 1 pi pi 32000 Jun 29 08:21 random3.txt
-rw-r--r-- 1 pi pi 31884 Jun 29 11:20 random3.txt.rx
$ diff random3.txt random3.txt.rx
48,49c48
< z.FBhelb.lniBotxvdiB.d.CIaasgsG
< xspkztwAszGsng.CBGKgG..uH.mdJFB
---
> z.FBB
51,53c50
< fAkAmqDjGjgJJHCqhnAuwADduC.qpwy
< uaA.fItoACnwxgcGohkIDKpyqewzlKb
< x.Bvcvai.uvneCpCcwEKdAluJhImkEn
---
> fAkAmqDjGjgJJHCqhnAuwADdEKdAluJhImkEn
$

Some guide how to use e32 utility in daemon mode

I want to use e32 utility in daemon mode. Do you have some article or how-to? Thanks

release new version after dockerfile

Can we have a new version released with the changes made in #17?

Buffer overflow

Had a heck of a time getting this working on something other than a raspberry pi. I was getting buffer overflow errors. Finally got it working on a Pine64 and Orange Pi Zero. Had to make a couple of code changes:

On devices other than a raspi the gpio pins can be 3 digits (on mine I'm using gpio231 and gpio362), so...

In gpio.c changed the size of the path variable in all those functions from 33 to 64.
In gpio.c changed the size of the val variable in gpio_exports to 4.
In gpio.c changed the filter function to allow a length of 7 for the directory enumeration so that pins like gpio362 will work.

I've never done a pull request on an open source project, but I will work on getting one ready with these changes.
I also had to change the default pins it uses to work on my project because I haven't quite figured out why your logic for exporting pins isn't working on armbian even with root privileges.

Anyways, sent a message for the first time today finally. Looking forward to play more with this. Thanx!