Closed EmilM256 closed 4 years ago
The actual silicon chip in those modules is SX1278 (or one of its variants) - as far as I can tell, HopeRF only puts it in a different package, and calls it RFM95/96/97/98.
The ranges in the library are taken from HopeRF's datasheet. This is true for all parameter ranges for all modules in RadioLib - I try to stick with manufacturer documentation as close as possible, since that's the official source of information. RFM95/96/98 datasheet specifies the following bands for the frequency output:
Next, regarding your particular RFM95/96 module: the silicon chip inside will most likely be able to handle 434 MHz band just fine. As a matter of fact, all the SX127x variants work in that band - the table below is from datasheet provided by Semtech (the actual silicon manufacturer)
You can see that all of the variants support at least the 137 - 525 MHz range. However, this only concernes the chip itself - not the passive components, like impedance matching circuit or the RF switch. These will have a rather narrow band, and using the module outside of it will cause a lot of attenuation. Just like you observed in your test, in 434 MHz band, the signal is much weaker.
My educated guess is that you have RFM95 chip incorrectly labeled as RFM96 on the package. However, I'm reluctant to change the frequency range based on the ID in version register. According to the datasheet, the only possible value should be 0x11 for all RFM9x chips. While this is demonstrably not the case at least for some portion of RFM9x chips on the market, there's no way to tell which variant (RFM95 or RFM96) has the "inteded" value. For that reason I think the best solution will be to make both 0x11 and 0x12 valid for all RFM9x chips, and leave the decision of the module to use up to user.
In my opinion, the bottom line here is don't buy chinese knockoffs. There's no reason to buy RFM9x over SX127x.
Frequency error is the difference between expected and real carrier frequency of the last received packet, which can be useful in some scenarios (for example in narrow band settings when not using temperature-compensated oscillator). If you call that function with autoCorrect set to true, it will attempt LoRa modem data rate PPM adjustment as per datasheet. I haven't yet encoutered a situation when that would be necessary.
I agree that the parameters in Radiolib are selected correctly. However, counterfeit manufacturers apparently do not care about the correct RFM95_CHIP_VERSION. There are many quarrels in the comments about it on the auction sites from China. Information about this error can help many people.
For that reason I think the best solution will be to make both 0x11 and 0x12 valid for all RFM9x chips, and leave the decision of the module to use up to user.
I think it's the best solution, plus information in the documentation.
0x12 has been added as valid device ID for all RFM9x modules in 3a15335b590fdd55817472dbd87906284aa6b317, could you check that it resolves the issue?
I checked RadioLib-3a15335. I have run examples sketches for STM32F1 and Arduino Pro Mini. RFM95 lora = new Module (PB0, PB1, PB10, PB11); int state = lora.begin (868.0, 125.0, 7, 5, 0x12);
Everything works fine, transmission and receiving was successful. :)
Below are logs from the debug mode:
[SX1278] Initializing ... R 42 12
SX127x not found! (1 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (2 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (3 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (4 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (5 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (6 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (7 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (8 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (9 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (10 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
No SX127x found!
R 42 12
Found SX127x!
R 1 F
W 1 9
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
W 1 89
R 1 89
R 1 89
R 1 89
W 1 89
R 1 89
R 39 12
W 39 12
R 39 12
R 1 89
W 1 89
R 1 89
R B 2B
W B 2B
R B 2B
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 24 0
W 24 0
R 24 0
R 1 89
W 1 89
R 1 89
R 6 6C
W 6 D9
R 6 D9
R 7 80
W 7 0
R 7 0
R 8 0
W 8 0
R 8 0
R 1 89
R 1 89
W 1 89
R 1 89
R 1D 72
W 1D 72
R 1D 72
Symbol length: 0.01 ms
R 26 4
W 26 4
R 26 4
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 74
R 1E 74
R 31 C3
W 31 C3
R 31 C3
R 37 A
W 37 A
R 37 A
Symbol length: 1.02 ms
R 26 4
W 26 4
R 26 4
R 1 89
R 1 89
W 1 89
R 1 89
R 1D 72
W 1D 72
R 1D 72
R 1 89
W 1 89
R 1 89
R 9 4F
W 9 CF
R 9 CF
R 9 CF
W 9 FF
R 9 FF
R 4D 84
W 4D 84
R 4D 84
R 1 89
R 1 89
W 1 89
R 1 89
R 26 4
W 26 4
R 26 4
success!
[SX1278] Transmitting packet ... R 1 89
W 1 89
R 1 89
R 1 89
R 1D 72
R 1E 74
R 20 0
R 21 8
R 1 89
W 1 89
R 1 89
R 1 89
R 40 0
W 40 40
R 40 40
R 1 89
W 12 FF
R 22 1
W 22 C
R 22 C
R E 80
W E 0
R E 0
R D 0
W D 0
R D 0
W 0 48 65 6C 6C 6F 20 57 6F 72 6C 64 21
R 1 89
W 1 8B
R 1 8B
R 1 89
W 12 FF
R 1 89
W 1 89
R 1 89
success!
[SX1278] Datarate: 2431.36 bps
[SX1278] Transmitting packet ... R 1 89
[SX1278] Initializing ... R 42 12
SX127x not found! (1 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (2 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (3 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (4 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (5 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (6 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (7 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (8 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (9 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
R 42 12
SX127x not found! (10 of 10 tries) SX127X_REG_VERSION == 0x12, expected 0x0011
No SX127x found!
R 42 12
Found SX127x!
R 1 9
W 1 9
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
W 1 89
R 1 89
R 1 89
R 1 89
W 1 89
R 1 89
R 39 12
W 39 12
R 39 12
R 1 89
W 1 89
R 1 89
R B 2B
W B 2B
R B 2B
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 24 0
W 24 0
R 24 0
R 1 89
W 1 89
R 1 89
R 6 6C
W 6 D9
R 6 D9
R 7 80
W 7 0
R 7 0
R 8 0
W 8 0
R 8 0
R 1 89
R 1 89
W 1 89
R 1 89
R 1D 72
W 1D 72
R 1D 72
Symbol length: 0.01 ms
R 26 4
W 26 4
R 26 4
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 74
R 1E 74
R 31 C3
W 31 C3
R 31 C3
R 37 A
W 37 A
R 37 A
Symbol length: 1.02 ms
R 26 4
W 26 4
R 26 4
R 1 89
R 1 89
W 1 89
R 1 89
R 1D 72
W 1D 72
R 1D 72
R 1 89
W 1 89
R 1 89
R 9 4F
W 9 CF
R 9 CF
R 9 CF
W 9 FF
R 9 FF
R 4D 84
W 4D 84
R 4D 84
R 1 89
R 1 89
W 1 89
R 1 89
R 26 4
W 26 4
R 26 4
success!
[SX1278] Starting to listen ... R 1 89
W 1 89
R 1 89
R 1 89
R 40 0
W 40 0
R 40 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
W 1 8D
R 1 8D
success!
R 1 8D
R 13 C
R 1 8D
R 1 8D
W 1 89
R 1 89
R 12 50
R 0 48 65 6C 6C 6F 20 57 6F 72 6C 64 21
R 1 89
R 13 C
R 1 89
W 12 FF
[SX1278] Received packet!
[SX1278] Data: Hello World!
[SX1278] RSSI: R 1 89
R 1A 6C
R 1 89
R 19 25
-56.00 dBm
[SX1278] SNR: R 1 89
R 19 25
9.25 dB
[SX1278] Frequency error: R 1 89
R 28 F
R 29 4E
R 2A 40
W 27 4F
-5964.30 Hz
R 1 89
W 1 89
R 1 89
R 1 89
R 40 0
W 40 0
R 40 0
R 1 89
W 12 FF
R F 0
W F 0
R F 0
R D C
W D 0
R D 0
R 1 89
W 1 8D
R 1 8D
Thanks, in that case I think we can consider this resolved.
Yes, thank you for your help and for resolving the problem.
I tested the module with the RF96 chip, which reports as RFM95_CHIP_VERSION == 0x12. So it should work at 434MHz. However, RMF95, 868 MHz, Rev 1.2 is printed on the board of the module. A salesman from China also wrote that.
For the test I changed the file: RadioLib\src\modules\RFM9x\RFM95.h
I did the test on two modules, about 25cm apart. Antennas are straight wires, about 81mm long. Antennas arranged parallel to each other. (pictures in the attachment).
The test consisted of checking RSSI, for frequencies: 434.00MHz, 868MHz, 915MHz, 950MHz. (The last two tests lasted only a few seconds - banned band). Transmission was successful for every frequency! Here are the results of the sketches from the example:
The results are a huge surprise for me. At 434.00MHz the received signal was very weak - 93dBm. According to the author of the library, the RFM96 chip on the radio module works with this frequency.
868.00MHz is the operating frequency of the module (according to the manufacturer from China). RSSI was already much better, at an acceptable level of around 41dBm.
I was most surprised when I set the frequency to 915.00MHz and 950.00MHz. In this case, RSSI was 36dBm! I wish I could use this range.
I don't know how to interpret these results. I didn't do tests at long distances. I do not know the "real" frequency at which the system worked. I cannot access the spectrum analyzer.
I know that many people had a problem with these modules. For example, https://github.com/jgromes/RadioLib/issues/104
Maybe we should change the frequency range for the RFM95 module in the library, which reports 0x12? Maybe my test method was wrong?
I have one more question. I am concerned about Frequency error. In the documentation, I saw the getFrequencyError and autoCorrect functions. How to use it ?? This feature only works for packets received? Should it be included in two sketches?