Open isouriadakis opened 1 year ago
Hi @isouriadakis ,
To increase the verbosity of the packet forwarder you can recompile it with make debug
. Additionally you may add -DRADIOLIB_VERBOSE
to the CFLAGS line in the Makefile before recompiling.
Corrupted messages may indicate the node and the forwarder communicate on close, but not exactly matching frequencies, so you should check that as well. I've seen variations in the EU433 node transmission plans in the different node implementations. For e.g.:
Channel Number | Transmission Frequency in MHz | Bandwidth in KHz |
---|---|---|
1 | 433.175 | 125.0 |
2 | 433.375 | 125.0 |
3 | 433.575 | 125.0 |
4 | 433.775 | 125.0 |
5 | 433.975 / 433.175 | 125.0 |
6 | 434.175 / 433.375 | 125.0 |
7 | 434.375 / 433.575 | 125.0 |
8 | 434.575 / 433.775 | 125.0 |
Perhaps you can try some of those blessed frequencies too.
Hi, @zhgzhg ,
Thanks for the quick reply. I still face exactly the same issues by choosing one of the blessed frequencies, specifically 433.575.
The weird part is that by using the exact same module and the radio lib library on Teensy40 I can receive the messages properly.
Any other thoughts on that? I feel like something is wrong with the SPI
Target LoRa Chip Model: SX1278
SPI Settings:
SPI port=1
SPI channel=0
SPI clock speed=5000000 Hz
(WiringPI) Pins:
nss_cs=6
dio0=7
dio1=4
rest=0
LoRa SX1278 Chip:
Freq=433.575000 MHz
BW=125.000 KHz
SF=7
CR=4/5
SyncWord=0x34
PreambleLength=8
Meta Information:
Latitude=37.925915
Longtitude=23.691095
Altitude=50 meters
Name/Definition: 1chan_uplink_pkt_fwd
E-mail: contact@email.com
Description: OPiPC LoRa 1-Ch GW
R 42 12
M SX127x
R 1 9
R 1 9
W 1 9
R 1 9
R 24 5
W 24 0
R 24 0
R 1 9
R 1 9
R 1 9
W 1 8
R 1 8
R 1 8
W 1 88
R 1 88
R 1 88
R 1 88
W 1 89
R 1 89
R 1 89
R 1 89
R 1 89
W 1 89
R 1 89
R 39 12
W 39 34
R 39 34
R 1 89
R 1 89
W 1 89
R 1 89
R b 2b
W b 23
R b 23
R 1 89
R 1 89
W 1 89
R 1 89
R 1 89
R 20 0
W 20 0
R 20 0
R 21 8
W 21 8
R 21 8
R 1 89
R 1 89
R 1 89
W 1 89
R 1 89
R 1d 72
W 1d 72
R 1d 72
Symbol length: 0.008 ms
R 26 4
W 26 4
R 26 4
R 24 0
R 1 89
R 1 89
W 1 89
R 1 89
R 6 6c
W 6 6c
R 6 6c
R 7 80
W 7 64
R 7 64
R 8 0
W 8 cd
R 8 cd
R 1 89
R 1 89
R 1 89
W 1 89
R 1 89
R 1d 72
W 1d 72
R 1d 72
R 1e 70
W 1e 70
R 1e 70
R 31 c3
W 31 c3
R 31 c3
R 37 a
W 37 a
R 37 a
Symbol length: 1.024 ms
R 26 4
W 26 4
R 26 4
R 1 89
R 1 89
R 1 89
W 1 89
R 1 89
R 1d 72
W 1d 78
R 1d 78
R 1 89
R 1 89
W 1 89
R 1 89
R 9 4f
W 9 cf
R 9 cf
R 9 cf
W 9 f8
R 9 f8
R 4d 84
W 4d 84
R 4d 84
R 1 89
R 1 89
W 1 89
R 1 89
R 1 89
R 26 4
W 26 4
R 26 4
R 1 89
R 1 89
W 1 89
R 1 89
R b 23
W b 2b
R b 2b
R 1 89
R 33 27
W 33 27
R 33 27
R 33 27
W 33 26
R 33 26
R 3b 1d
W 3b 1d
R 3b 1d
R 1 89
R 1e 70
W 1e 74
R 1e 74
LoRa chip setup succeeded! Waiting for data...
R 1 89
R 1 89
W 1 89
R 1 89
R 1 89
R 1 89
R 1 89
W 1 89
R 1 89
R 1 89
R 24 0
R 40 0
W 40 0
R 40 0
R 1 89
R 1 89
R 1 89
W 1 89
R 1 89
R 24 0
R 1 89
R 1 89
W 1 89
R 1 89
R 6 6c
W 6 6c
R 6 6c
R 7 64
W 7 64
R 7 64
R 8 cd
W 8 cd
R 8 cd
R 31 c3
W 31 43
R 31 43
R 2f 40
W 2f 40
R 2f 40
R 30 0
W 30 0
R 30 0
R 1 89
W 12 ff
R f 0
W f 0
R f 0
R d 0
W d 0
R d 0
R 1 89
R 1 89
W 1 8e
R 1 8e
Weird indeed. At first glance it looks okay.
How is the transmitter node implemented - is from the Transmit example? It's important when the node is about to transmit to have its IQ inversion turned on.
Also, although you've already mentioned please try lowering the SPI frequency to let's say 1000000
.
Yeah using the Transmit example and IQ is on
I manage to get those two messages
(Fri Jan 13 15:36:53 2023) Received UPlink packet:
RSSI: -71.0 dBm
SNR: 6.750000 dB
Frequency error: -1065.353271 Hz
Data: 1 bytes
0000 5f _
R 1 89
R 1 89
W 1 89
R 1 89
R 1 89
R 1 89
R 1 89
W 1 89
R 1 89
R 1 89
R 24 0
R 40 0
W 40 0
R 40 0
R 1 89
R 1 89
R 1 89
W 1 89
R 1 89
R 24 0
R 1 89
R 1 89
W 1 89
R 1 89
R 6 6c
W 6 6c
R 6 6c
R 7 64
W 7 64
R 7 64
R 8 cd
W 8 cd
R 8 cd
R 31 43
W 31 43
R 31 43
R 2f 40
W 2f 40
R 2f 40
R 30 0
W 30 0
R 30 0
R 1 89
W 12 ff
R f 0
W f 0
R f 0
R d 1
W d 0
R d 0
R 1 89
R 1 89
W 1 8e
R 1 8e
R 1 89
R 1 89
R 1 89
W 1 89
R 1 89
R 1 89
R 13 11
R 12 50
R 1c 40
R 0 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 20 23 31 33 31
R 1 89
W 12 ff
R 1 89
R 13 11
R 1 89
R 1a 71
R 1 89
R 19 1b
R 1 89
R 19 1b
R 1 89
R 28 f
R 29 9c
R 2a c0
(Fri Jan 13 15:36:53 2023) Received UPlink packet:
RSSI: -51.0 dBm
SNR: 6.750000 dB
Frequency error: -3330.277344 Hz
Data: 17 bytes
0000 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 20 23 31 33 Hello World! #13
0100 31 1
R 1 89
R 1 89
W 1 89
R 1 89
R 1 89
R 1 89
R 1 89
W 1 89
R 1 89
R 1 89
R 24 0
R 40 0
W 40 0
R 40 0
R 1 89
R 1 89
R 1 89
W 1 89
R 1 89
R 24 0
R 1 89
R 1 89
W 1 89
R 1 89
R 6 6c
W 6 6c
R 6 6c
R 7 64
W 7 64
R 7 64
R 8 cd
W 8 cd
R 8 cd
R 31 43
W 31 43
R 31 43
R 2f 40
W 2f 40
R 2f 40
R 30 0
W 30 0
R 30 0
R 1 89
W 12 ff
R f 0
W f 0
R f 0
R d 11
W d 0
R d 0
R 1 89
R 1 89
W 1 8e
R 1 8e
Using the other library I was getting RSSSI =-30
Hmm, at least the SNR is strong. The RSSI value of this project should be more accurate, because of RadioLib. But the frequency error is larger than usual. If the devices are close to each other the latter shouldn't be the case. I'm not sure if the small proximity is impacting the results negatively though.
Regarding the short 1 byte packet - I assume it's a glitch. I've seen similar results when for e.g. the power of the node is shut down or briefly interrupted, sometimes it's still able to transmit 1 more packet similar to yours. Do you see such packets when running the other project?
The frequency error is weird, the RSSI when using RadioLib on Teensy is much better. Probably has something to do with the Pi 4?
The 1 byte packet was correct, that was not an issue.
The two devices are right next to each other.
I don't think there are many things you can do. I will try to run a receive example in C similar to the receive example of the RadioLib for Arduino and start debugging from there.
In case I figure it out I will make a Pull request.
Sure, I'm clueless as well. It's possible to be hardware related. I've seen less reception and more noise on the single-board computers, which compared to MCUs like Teensy, and ESPxx have much noisier lines (incl. the power ones). The situation can be slightly improved with capacitors on the VCC and GND pins of the transceiver chip, or close to them. Combining several capacitors in parallel with different values may help - for e.g one capacitor of each: 10nF, 330nF, 100uF.
I don’t think is Hardware related in terms of actual hardware, it has to be the SPI implementation, because on the other library it works fine. I am receiving all the frames properly, no error or missing packets.
First of all, I want to thank you for your great effort.
I have noticed some weird behavior. Using this library I am not able to receive any messages, the few that I receive are mostly corrupted. I played around with a lot of SPI values with no success.
The weird part is that by using this library I was able to receive messages without a problem.
Any suggestions on how to debug this?
Some extra information I am using EU433, set the frequency at 434, and the rest is the default for EU433. I tried different CR and bandwidth with no success.
I would realy love to use your library as there are more options for setting the CR, Bandwith and sync word.