-
Notifications
You must be signed in to change notification settings - Fork 17
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
Ebyte E22-900M22S: SPI Transaction error:10 #4
Comments
I find a possible solution. esp-idf-sx126x/components/ra01s/ra01s.c Line 935 in 09d3831
After this return is for me
Now I'm going to test if I can effectively communicate. |
What if you add a little wait here?
|
Ironically it now works without adding delay and without going through my retry loop. |
I think so, too. |
Updates:
Checking the rest of the log, it generates this retry only this first time when entering SetStandby(), other times it enters normally. |
Interesting i was about to post the same issue here.i face the same problem today trying the lib with an esp32-c3 and a e22 900m22s module. Can you provide a patch for your modification ? cause from the code snipet you posted above it is not clea where exactly to put it |
esp-idf-sx126x/components/ra01s/ra01s.c Line 935 in 09d3831
I don't know why this retry is needed only when entering SetStandby(). The real cause may be different. |
I was searching for an Now my dump of execution is :
by the way where can i find error code table like what |
@joaoceresoli from my understanding In the issue tittle you reference |
|
As far as I can tell, status bytes is almost always returned when the microcontroller is sending data to the SX126x. From DS_SX1261-2_V2_1.pdf: 0xA2(0b 1010 0010) is STBY_RC + RFU E22-900M22S_UserManual_EN_v1.4.pdf does not have a description about Status |
Really, i'm sorry, you are correct, my lora module has a semtech sx126x, not a llcc... I remember reading that the registers of the sx126x and llcc68 modules were the same, the evolution of the chip would be in the part of improvements in the RF circuit, but I could be wrong. |
LLCC68 is compatible with SX126X. BW is either 125KHz, 250KHz or 500Khz. Ai-Thinker's Ra-01SC uses LLCC68. This repository works correctly with Ra-01SC (LLCC68). |
From what I know sf 5 and sf 6 are not compatible with sx127*
Le mar. 26 juil. 2022, 12:24, nopnop2002 ***@***.***> a
écrit :
… LLCC68 is compatible with SX126X.
However, LLCC68 has the following restrictions:
BW is either 125KHz, 250KHz or 500Khz.
When BW is 125KHz, SF is in the range of 5-9.
When BW is 250KHz, SF is in the range of 5-10.
When BW is 500KHz, SF is in the range of 5-11.
—
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA2FCTH4MZDRWAOJ5HE4XGDVV64ETANCNFSM52UQO2IQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
You should rename the repo then :) |
can someone explain to me the following test on getstatus() ?
i dont understand the logic to test first 01110000 to test 01010000 at the end cause i dont see what 0111 is masking |
https://github.com/nopnop2002/esp-idf-sx126x/blob/main/components/ra01s/ra01s.c#L681 This confirms whether the chip mode is RX. Check 11 times, and if it is not RX yet, execute ESP_LOGE (TAG, "SetRx Illegal Status") ;. |
and why not test like this : if ((GetStatus() & 0x50) == 0x50) break; ? |
This is same. Both have the same result if ((GetStatus() & 0x70) == 0x50) break; if ((GetStatus() & 0x50) == 0x50) break; |
The module is not entering rx state it return 2a @joaoceresoli are you able to share your code? on how you achieved sending and receving data ? |
@netmonk Give my a some time to adjust my code for example model. |
You can read the modification i have made for module E22-900M22S work. |
thank you @joaoceresoli it works, it think the main point was about powering the tcxo. i guess it's time to adapt the library to support differents modules, by itself.. |
Try this change without any other changes and see if it works. I want to know the reason why a retry is necessary.
|
For me, I will try to investigate with a oscilloscope the mosi pin during write transaction. There can be some error of pull-up/pull-down |
It's good way. |
I have a same issue that previous, but in a different module.
I use a Ebyte e22-900m22s module, that have a LoRa chip llcc68, its seems a semtech 126x.
The data from this devices is here and here.
Output from my log.
I decided to remove the while(1) lock for when an error occurs, in order to check if all registers generated errors, I noticed that not all of them, here is my output:
I noticed that the possible problem for the previous question was in tcxoVoltage, however I didn't understand how this parameter works and what value exactly I have to configure.
The text was updated successfully, but these errors were encountered: