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
SARA-R510S keeps CTS line sporadically high if DTR is used for power saving #192
Comments
Hi @eeFLis: can't say this is something we've noticed, @philwareublox is going to check internally. |
@eeFLis: some questions. You say that the module allows the |
Hi I have attached the salea capture. However, this was already recorded some time ago with the module fw version 03.15, A00.01, but should show the problem |
Can you confirm that you are using the default value for U_CELL_PWR_UART_POWER_SAVING_GSM_FRAMES, so
|
Yes, we use the default value. Were you able to gather all the information from the salea capture or do you need additional information? |
I've been staring at it with the relevant expert internally. If you look at the picture below, at the green marker is where the module emits a 12 seconds later comes the problematic part, focusing on that: You can see, in the middle of the picture, that the module has allowed Pure speculation, of course, but a guess would be that something to do with the fact that the module is autonomously coming out of [EDIT: I meant going into] 32 kHz sleep at the same moment as Will continue to investigate... |
you mean > at the same moment as |
Sorry, yes at the same moment as |
Out of interest, are you able to read the state of the |
If you have additional Saleae captures of the problem then we could check if they look the same but no matter if you don't. |
Unfortunately I have no additional capture. |
Yes, not exactly sure what the workaround would be really. Haven't been able to think of anything yet that would not introduce a new problem. Will carry on thinking... |
One more question: do you know if the problem goes away if you set |
It already goes away when we set the |
Thanks for confirming, understood, the aim is of course to retain the power-saving goodness, just wanted to be sure of the problem. |
Just for my information, if you set Is this an approach you have tried? |
Yes we are using this approach. That's what I tried to say with "we set The additional consumption is mainly noticeable after RRC connection ist released and the timer T3324 is running. I understand that the extra consumption doesn't look like much but if you're focusing on low power it's a crucial. |
For my own clarity, are you saying without using the DTR line to drop the consumption of the UART you're then seeing the basic 6 second timeout for the UART. Whereas if you were able to use the DTR line successfully every time without this CTS issue, you can immediately control the UART on/off state as you want to. |
yes. As an example: during the active time (T3324) when data can still be received, the ubxlib is polling for new incomning data. If the DTR line is used for power saving control the module can switch to power save mode immediately after the response. |
@philwareublox and I have been discussing this, maybe there is a way forward. Background first:
A fix, then, might be to offer a function something like Could that work? |
I think ubxlib already offers a solution for this. We use |
However, this only solves the problem for the example I mentioned. |
or do you see a problem with the use of |
It should work, I guess the only problem might be if there is a lag between when the URC arrived to updated the number and when the application called We will continue thinking. |
OK thanks. In the meantime, are there any further findings as to where the error comes from when DTR is active? |
The expert internally is trying to reproduce the problem, just now looking to find the same FW version as you are using, to be quite sure about it. It is a strange case: the |
FYI, the expert internally has your FW version now and is trying to script some form of sliding-delay-window of " Wondering idly: I guess you have a callback hooked into uCellNetSetBaseStationConnectionStatusCallback()? I understand that the |
thanks for the update |
True: if it is the case [as I think it is] that SARA-R5 cannot run the UART from a 32 kHz clock then every AT communication pulls the modem out of 32 kHz sleep and the only way to get back in is by letting I was think that, if you could know that the module was not going to enter 32 kHz sleep anyway (which might be after All a bit complex, and vague, I know. |
I have done a few more tests. |
Oh, that's excellent, thanks very much for taking the time to do this, I will pass it on to the right person and get back to you. |
Browsing the Saleae log (I'll leave it up to the expert to view the OTII log as Windows Defender seems to have decided the OTII 3 application is a trojan on my laptop and keeps closing it), just to confirm the area of interest, it is here: ...zooming in a bit: ...and zooming in again, the last thing that happens being an ...zooming in again, ...and stays there for 100 seconds, until you pull the plug. During that time there are no URCs, Is that a correct interpretation? Anything I've missed? |
For the benefit of our internal expert, I've exported from the Saleae log the AT exchange in the portion of interest, i.e. after coming out of PSM the second time, and transcribed it as best I can below; all pretty standard One interesting thing is that the module seems to be still connected when the problem occurs (we have not seen a
|
OK, our internal expert has been staring at the Saleae and Otii logs and is wondering if the issue is that, around the point of failure, I will add code to |
Yes for sure |
Actually, better than that, the code is already there (I'd obviously anticipated something of this nature and then forgotten): U_CELL_PRIVATE_DTR_PIN_HYSTERESIS_INTERVAL_MS is set to U_AT_CLIENT_ACTIVITY_PIN_HYSTERESIS_INTERVAL_MS, which is 10 ms. Could you try overriding the conditional compilation flag |
Yes: the thinking is that there is a bug somewhere in the module FW which means that, if EDIT: this is backed-up by the fact that the module does not awaken again after about 60 seconds, you having left it for at least 100 seconds; normally, processes within the module would cause it to awaken by itself, if this is not happening then it is relatively seriously upset. Checking the code again, can I ask that, rather than defining EDIT: IGNORE WHAT I SAID ABOVE and set |
Apologies for the confusion, please stick with setting |
Unfortunately, the error still occurs Here is the recording |
Oh! That is interesting: seems like an exceptionally short wake-up (low |
should not have been set |
Gah, yes, you're right: there are two, one in the cellular code which is applied when things like CMUX need to disable I will look at how to do this better but, as you say, set |
should i reset U_CELL_PRIVATE_DTR_PIN_HYSTERESIS_INTERVAL_MS to the previous value? |
If you are not using CMUX (which I think is the case) then |
have checked it in the saleae trace should be ok now. |
The error has just occurred again. Do you need the trace? |
You're getting good at this :-|. The trace might be useful, if possible. |
:-) Would be happier if the error disappeared. Here the recording |
Hi @RobMeades Is there any news on this topic? |
I was wondering that myself: apparently the internal expert was side-tracked onto something else, they will get back to it today. |
...but now they've had a high priority interrupt onto something else, will update you when I know something... |
FYI, the internal expert is now back on this, investigating... |
Great, thanks for the information |
Probably not good news but, FYI, our internal SW expert has now deferred to our internal HW expert: it seems that, on SARA-R5, when He has tried various SW workaround but so far has found nothing which can be guaranteed to avoid this window. Here's hoping the internal HW expert can find something we can use. |
The good thing is that the cause of the problem could be identified. |
Hi @RobMeades Do you have any news from the HW expert on this? |
Sorry for the delay in this: I'm told the HW team are currently discussing it, will get back to you when they have something to say. |
Hi
maybe no ubxlib related problem, but perhaps you have already observed this behavior
If the DTR pin is used for power saving, the SARA R510 s module sporadically holds the CTS line high and no longer releases it.
the module is then no longer responsive.
we had the problem several times with the module firmware version 03.15, A00.01.
We hoped that this problem would be solved with the current module firmware version 03.30, A00.01, but the problem still occurs, even if it is much less frequent (after hours ).
Have you observed such behavior in your test environment?
The text was updated successfully, but these errors were encountered: