-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not receiving messages #12
Comments
Hi @isouriadakis , To increase the verbosity of the packet forwarder you can recompile it with Corrupted messages may indicate the node and the forwarder communicate on close, but not exactly matching frequencies,
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 |
|
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 |
Yeah using the Transmit example and IQ is on I manage to get those two messages
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). |
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.
The text was updated successfully, but these errors were encountered: