Skip to content
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

SX1262 shows a lower SNR than SX1276 based boards #332

Closed
drewsed opened this issue Aug 22, 2020 · 11 comments
Closed

SX1262 shows a lower SNR than SX1276 based boards #332

drewsed opened this issue Aug 22, 2020 · 11 comments
Labels
bug Something isn't working

Comments

@drewsed
Copy link

drewsed commented Aug 22, 2020

Hi,

I recently received my two TBeam 1.1 with the new SX1262 LoRa module and it seems that the signal strength calculation is somehow different than with SX1276.

Board Link: https://www.aliexpress.com/item/LILYGO-TTGO-T-Beam-V1-1-SX1262-LORA-868-915MHZ-ESP32-WiFi-Wireless-Bluetooth-Module-GPS/4001287221970.html?spm=a2g0s.9042311.0.0.46b94c4dJdZvPj

Aso mentioned on forum:
https://meshtastic.discourse.group/t/tbeam-with-sx1262/972/18?u=drewsed

@geeksville
Copy link
Member

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/tbeam-with-sx1262/972/22

@geeksville
Copy link
Member

hmm interesting. I just tried two different SX1262 based boards receiving from a old TBEAM. On both boards the RXSNR for the packet was 7dBm.

One receiver was a SX1262 TBEAM and the other was a NRF52840+official sematech SX1262 eval board. So it looks like the receive RX performance is pretty close between the TBEAM and the ref board. I also checked the getSNR function and its implementation matches the SX1262 datasheet, so I think it is calculating correctly.

I'll now need to check the old SX1278/RF95 getsnr function, which would have declared about 10dBm for this test. Perhaps it is wrong?

@geeksville geeksville changed the title Wrong signal strength calculation on SX1262. SX1262 shows a lower SNR than SX1276 based boards Aug 23, 2020
geeksville added a commit to meshtastic/RadioLib that referenced this issue Aug 23, 2020
geeksville added a commit to meshtastic/RadioLib that referenced this issue Aug 23, 2020
geeksville added a commit to meshtastic/RadioLib that referenced this issue Aug 23, 2020
@geeksville geeksville added this to To do in Meshtastic work Aug 25, 2020
@geeksville
Copy link
Member

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/tbeam-with-sx1262/972/25

@mc-hamster
Copy link
Member

@drewsed Could you retest this with the latest firmware? I fixed a setting in our use of the sx1262 library that may have caused the problem you described.

#466

@drewsed
Copy link
Author

drewsed commented Nov 1, 2020

@mc-hamster sure, but unfortunately it did not solve the issue for me. I did the update via bt, so do you think things will change if i do a clean serial flash?

My tbeams (1.1.7) show a signal strength of 77%, 80% and 85%, while both heltecs (1.1.7) show 97%, 100% and 100%

@mc-hamster
Copy link
Member

Hmm ...

The receive signal strength should not have anything to do with the configuration. It’s all hard coded.

I’ll keep an eye out. Could also be the scale is being reported different.

Worth a shot. Thanks for retesting.

@mc-hamster
Copy link
Member

mc-hamster commented Nov 22, 2020

More data.

On a sx1276, I got measured an rssi of -59 with a snr of 5. My noise floor is at -87.

With a signal attenuator attached to a device, I got an rssi of -94 and a snr of 5.5 with the same noise floor.

With the signal attenuator attached, I should have gotten a negative snr from the device.

@mc-hamster
Copy link
Member

mc-hamster commented Nov 22, 2020

The sx127x data sheet on page 112 describes the snr value register as:

Estimation of SNR on last packet received.In two’s compliment
format mutiplied by 4.

The sx126x data sheets on page 97 describes the snr value register as:

Estimation of SNR on last packet received in two’s compliment format multiplied by 4.

The only difference between the two is the misspelling in the 127x data sheet.

@geeksville
Copy link
Member

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/inconsistent-reported-signal-on-oled-screen/2340/2

osmanovv pushed a commit to osmanovv/RadioLib that referenced this issue Aug 22, 2021
@garthvh garthvh added the bug Something isn't working label Jan 24, 2022
@garthvh
Copy link
Member

garthvh commented May 1, 2022

@thebentern Closing this as it seems related to the 1262 power updates

@garthvh garthvh closed this as completed May 1, 2022
Meshtastic work automation moved this from To do to Done May 1, 2022
@vemanthchandrap
Copy link

Hey guys, hope you are doing good. this is my first project. I took two Lilygo tbeam axp2101-v1.2 for my Lora project. I need to find RSSI and SNR values. i have codes for transmitter and receiver and i am using LoRa library by sandeep mistry in arduino ide. I used TTGO LoRa32 OLED as my board and i didn't get any error in the output, but i can't see any output values in serial monitor. anyone can help me with this. Please help me I am clueless, any chances I need to do to get the values on serial monitor. I used the codes from https://randomnerdtutorials.com/ttgo-lora32-sx1276-arduino-ide/

output:
Sketch uses 280941 bytes (21%) of program storage space. Maximum is 1310720 bytes.
Global variables use 22388 bytes (7%) of dynamic memory, leaving 272524 bytes for local variables. Maximum is 294912 bytes.
esptool.py v4.5.1
Serial port COM11
Connecting....
Chip is ESP32-D0WDQ6-V3 (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 34:98:7a:6b:f7:a0
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00005fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x00054fff...
Compressed 17568 bytes to 12204...
Writing at 0x00001000... (100 %)
Wrote 17568 bytes (12204 compressed) at 0x00001000 in 0.5 seconds (effective 295.2 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 146...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (146 compressed) at 0x00008000 in 0.1 seconds (effective 391.8 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 493.3 kbit/s)...
Hash of data verified.
Compressed 281312 bytes to 152630...
Writing at 0x00010000... (10 %)
Writing at 0x0001d278... (20 %)
Writing at 0x000250b1... (30 %)
Writing at 0x0002a328... (40 %)
Writing at 0x0002f84c... (50 %)
Writing at 0x00034dac... (60 %)
Writing at 0x0003d6a4... (70 %)
Writing at 0x0004812f... (80 %)
Writing at 0x0004d6ff... (90 %)
Writing at 0x00052ebb... (100 %)
Wrote 281312 bytes (152630 compressed) at 0x00010000 in 2.6 seconds (effective 881.1 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
No open projects
Development

No branches or pull requests

5 participants