-
Notifications
You must be signed in to change notification settings - Fork 51
Add SNR property according to datasheet #59
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
Conversation
|
@jerryneedell do you have a chance to look at this? |
Format with Black
e330bd6 to
cefd778
Compare
|
@brentru sure -- will take a look. |
jerryneedell
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. One suggestion:
For the RSSI - we have 2 ways to read it.
the .rssi property is the instantaneous RSSI stored
the .last_rssi is saved immediately after the packet is received.
I just ran some tests and I get the same reading fo riot, but as I recall, there were times when they were different . I don't know if the same applies to SNR.
If you want, we could add .last_snr in the same way -- I tried it and as with the RSSI, I get the same reading
here are the changes I made:
pi@gjnpilora:~/projects/blinka/rfm9x_ack $ diff adafruit_rfm9x.py ~/projects/adafruit_github/Adafruit_CircuitPython_RFM9x/adafruit_rfm9x.py
289,293d288
< self.last_snr = 0.0
< """The SNR of the last received packet. Stored when the packet was received.
< The instantaneous SNR value may not be accurate once the
< operating mode has been changed.
< """
790,791d784
< # save last RSSI reading
< self.last_snr = self.snr
As to the value returned, I have no way to determine its correctness but I think you have implemented it correctly.
Let me know what you think of adding the .last_snr properly as well.
|
With the added values I get the same results I'll see if I can reproduce a case with some deviation |
|
Sound like a good idea to implement a "last" SNR as well to prevent the value changing in the register after receiving a packet but before we read the value after processing the current packet.
28 Jan 2021 20:21:19 jerryneedell <[email protected]>:
… @jerryneedell requested changes on this pull request.
This looks good to me. One suggestion:
For the RSSI - we have 2 ways to read it.
the .rssi property is the instantaneous RSSI stored
the .last_rssi is saved immediately after the packet is received.
I just ran some tests and I get the same reading fo riot, but as I recall, there were times when they were different . I don't know if the same applies to SNR.
If you want, we could add .last_snr in the same way -- I tried it and as with the RSSI, I get the same reading
here are the changes I made:
***@***.***:~/projects/blinka/rfm9x_ack $ diff adafruit_rfm9x.py ~/projects/adafruit_github/Adafruit_CircuitPython_RFM9x/adafruit_rfm9x.py 289,293d288 < self.last_snr = 0.0 < """The SNR of the last received packet. Stored when the packet was received. < The instantaneous SNR value may not be accurate once the < operating mode has been changed. < """ 790,791d784 < # save last RSSI reading < self.last_snr = self.snrAs to the value returned, I have no way to determine its correctness but I think you have implemented it correctly.
Let me know what you think of adding the .last_snr properly as well.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub[#59 (review)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/ABXBTVVXZ775W2TY64TDNELS4HBLLANCNFSM4WXT3VFA]. [https://github.com/notifications/beacon/ABXBTVUGQOTOVE3DAKRP7QDS4HBLLA5CNFSM4WXT3VFKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOEJ7GI5A.gif]
|
|
Great. If you can implement that and push a new commit, it should be ready to go. |
|
Here is more information on the history of "last_rssi" implementation adafruit/Adafruit_CircuitPython_RFM69#22 |
|
I've implemented the requested changes for adding last_snr attribute to the class. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! -- Looks good to me! Tested on Raspberry Pi ZeroW with RFM9x Bonnet.
|
@brentru OK to merge this? |
|
@jerryneedell Looks OK to me, go ahead :) |
|
Thanks all, Hope to contribute more in future :) |
|
@AdamLeyshon Thank you! We look forward to future contributions! |
|
BTW -- I also made a new release - v 2.1.2 -- should be available via PyPy soon and in the library bundle tonight. |
Updating https://github.com/adafruit/Adafruit_CircuitPython_CharLCD to 3.3.6 from 3.3.5: > Merge pull request adafruit/Adafruit_CircuitPython_CharLCD#56 from adafruit/dherrada-patch-1 Updating https://github.com/adafruit/Adafruit_CircuitPython_CircuitPlayground to 4.3.0 from 4.2.1: > Merge pull request adafruit/Adafruit_CircuitPython_CircuitPlayground#102 from adafruit/dherrada-patch-1 > Merge pull request adafruit/Adafruit_CircuitPython_CircuitPlayground#101 from kattni/cleanup-deprecated-code > Merge pull request adafruit/Adafruit_CircuitPython_CircuitPlayground#99 from mw46d/main Updating https://github.com/adafruit/Adafruit_CircuitPython_IRRemote to 4.0.3 from 4.0.2: > Merge pull request adafruit/Adafruit_CircuitPython_IRRemote#43 from adafruit/dherrada-patch-1 Updating https://github.com/adafruit/Adafruit_CircuitPython_LSM303DLH_Mag to 1.1.5 from 1.1.4: > Merge pull request adafruit/Adafruit_CircuitPython_LSM303DLH_Mag#11 from askpatrickw/fix-repo-url-typo Updating https://github.com/adafruit/Adafruit_CircuitPython_MPR121 to 2.1.5 from 2.1.4: > Merge pull request adafruit/Adafruit_CircuitPython_MPR121#30 from adafruit/dherrada-patch-1 Updating https://github.com/adafruit/Adafruit_CircuitPython_Nunchuk to 1.0.0 from 0.3.0: > Merge pull request adafruit/Adafruit_CircuitPython_Nunchuk#24 from jfurcean/add-values-property Updating https://github.com/adafruit/Adafruit_CircuitPython_RFM9x to 2.1.2 from 2.1.1: > Merge pull request adafruit/Adafruit_CircuitPython_RFM9x#59 from AdamLeyshon/add_snr_property Updating https://github.com/adafruit/Adafruit_CircuitPython_Wiznet5k to 1.9.0 from 1.8.0: > Merge pull request adafruit/Adafruit_CircuitPython_Wiznet5k#31 from xorbit/master Updating https://github.com/adafruit/Adafruit_CircuitPython_AdafruitIO to 5.1.0 from 5.0.4: > Merge pull request adafruit/Adafruit_CircuitPython_AdafruitIO#62 from brentru/create-group-feed > Merge pull request adafruit/Adafruit_CircuitPython_AdafruitIO#61 from brentru/small-feed-names > Merge pull request adafruit/Adafruit_CircuitPython_AdafruitIO#60 from askpatrickw/fix-repo-url-typos Updating https://github.com/adafruit/Adafruit_CircuitPython_AVRprog to 1.3.4 from 1.3.3: > Merge pull request adafruit/Adafruit_CircuitPython_AVRprog#20 from adafruit/dherrada-patch-1 Updating https://github.com/adafruit/Adafruit_CircuitPython_Motor to 3.2.5 from 3.2.4: > Merge pull request adafruit/Adafruit_CircuitPython_Motor#51 from adafruit/dherrada-patch-1 Updating https://github.com/adafruit/Adafruit_CircuitPython_SimpleIO to 2.1.3 from 2.1.2: > Merge pull request adafruit/Adafruit_CircuitPython_SimpleIO#58 from askpatrickw/fix-repo-typo > Added pre-commit-config file Updating https://github.com/adafruit/Adafruit_CircuitPython_Bundle/circuitpython_library_list.md to NA from NA: > Added the following libraries: Adafruit_CircuitPython_datetime
Hello, I have implemented what I believe to be the correct function according to the datasheet for the RFM95W
(RFM95W-V2.0-1.pdf from HOPERF)
The register is at 0x19, it 8 bits wide and is a signed value stored as a single byte using two's complement and should be divided by 4 to get the dB value.
Tested on my own AdaFruit RFM95W Bonnet for Raspberry Pi and AdaFruit RFM95W Breakout board connected to a Raspberry Pi Pico running the latest Circuit Python (6.2 beta)
I receive values between 6 and 9 when the transmitting station is near by,
Unfortunately I have nothing to compare this value against to determine if what the hardware says is correct.
Please let me know if the implementation is incorrect.