-
Notifications
You must be signed in to change notification settings - Fork 90
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
Minimum cmd wait delay - required? #159
Comments
FYI, to make this a bit more concrete :
In case of the default time (100ms), in the exact same scenario, the time was double:
|
Hi again: you're busy :-). It's a tricky one, that parameter. Frankly it is kind of a "fudge factor" that, as I think your second question points to, can result in occasional instability if the corner is cut too far. The integration of SARA-R4 into The recommended value can be found in the SARA-R4 AT commands manual, section 2.2.5.1:
So, as you can see, 10 ms may work but then you need to know if it always works, where is the corner? As you can see from the presence of the The only dependable answer would be to run a good solid set of regression tests of your product with your choice of "trimmed" value: that would test your AT commands, in your use cases, on your choice of module. I would be reluctant to change the parameter for SARA-R4 in |
Hi :) Many thanks for the elaborate answer. It's indeed sort of what I was expecting. I can indeed bring it down a bit and evaluate. Thanks again, and I'm off to keeping busy:) |
Hmm, yes, maybe a function would be better. Shouldn't be difficult to add: it is on the TODO list. |
Generally a lot of this interaction should be able to self-pace as you always expect some OK/ERROR type response, and URC should be output interleaved at a line level, so there shouldn't be characters jumbled together. |
APIs to permit the AT command delay to be overridden added in a12674d (along with appropriate warnings). Gonna close this one, please feel free to re-open if we need to discuss further. |
Note, even though I took your code changes and lowered the AT delay timeout, I noticed that during my OTA download the transfers were -still- slow. (> 100ms delay between AT commands) Apparently this comes from u_sock.c, where a define I then tried to lower the requested buffer lower than that 1 kB, but still ran into 100ms delay. Note that in case of 115200 baud, the download utilization is about 1/3rd. But in case of higher baudrates, these delays would totally dominate the transfer. |
Trying to push it even further (sub 10ms) required:
That gives: Ideally I want to try to now change the baudrate and see what speed I can reach now too, but I understand this is a bit tricky. |
Very interesting: the timeout in a URC has been 100 ms pretty much since the AT Client was written. In theory there shouldn't be an issue reducing it, any partially received URC will be processed completely the next time around, but it is also true that, at some point, the AT Client needs to throw uninteresting received stuff away so the danger is that a URC could find its way into the bin if there was a hole in that logic and it would be difficult to determine that is happening; there is a static, back-to-backed, test jig for the AT Client but I wouldn't want to rely on it to pick up timing oddities. I will create a branch on which I can test a reduced |
In that case what I would do is add functions to the AT Client to set/get I would add a "HERE BE DRAGONS" comment above Does that present the right balance of risk/responsibility? |
Hi, sounds what I would use yes. Thanks for the help |
I've performed four complete test sweeps (1 hour runs of everything across all of the platforms we have in the test system) overnight with Now of course it is very difficult to be sure without looking through every single AT log but I would have expected some hint of a problem. What I will do is implement the API and also bring |
This is now done in 731256a. All the interfaces are added uCellAtCommandTimingGet(), uCellAtCommandTimingSet() and, to make things easy, uCellAtCommandTimingSetDefault(). The transmit delay times for SARA-R422 (and LARA-R6) are modified to be 20 ms. I did try reducing the |
Hi,
in cell/src/u_cell_private.c there is the structure
gUCellPrivateModuleList
which describes the different supported modules and their parameters. One of these iscommandDelayMs
, which causes a 100ms delay before each command that is sent.For my usecase, where I want to reach the cloud asap to avoid leaking power, I'd ideally loose as little time as possible going through setup procedures. Currently, the AT commands sent to check and set up the modem delay the boot quite a bit.
If you look at the UART bus, one can see that it is pretty idle because of this 100ms delay
The most important question I have about this, is whether this 100ms delay needed in the first place or not? (and where does it come from)
A second question could be if there are ways to safely "cut corners" - that's to say, currently I am assuming if I use the ubxlib functions to bring up my cellular connection - and I assume that this will always work correctly. If I start skipping AT commands (e.g. by assuming certain configurations are already done), I'd have to deviate from the library and also have less reliability So if possible, that's something I'd like to avoid. But hence the question if the commands cannot simply be sped up or not.
Thanks for your feedback
The text was updated successfully, but these errors were encountered: