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
Module AT.js: getData() returns garbage '\n' character #1512
Comments
Thanks - I think the issue here is that It's tempting to change the module to use Are you encountering this with the https://github.com/espruino/EspruinoDocs/blob/master/devices/QuectelBG96.js module? It seems that you could probably work around it using:
|
Actually, please can you wait a bit on this? I'll see about changing the AT module for |
Yes. I am dealing with the RAK8212, so I took this file and adapted it to not create GPRS connections, but LTE-M NB1 "Narrowband IoT" connections.
I will try out. Thanks. |
Ok, just done. That should improve things for you I hope, although you may need to tweak the handling of ATE0 in your copy (see the changes in espruino/EspruinoDocs@ebcb304) Hopefully this doesn't cause problems with other AT-command based devices, but I guess we'll see! As I mentioned in the forum, if you're happy to share it'd be great to be able to build your NB-IoT related changes into |
Thanks. Tried it out and it works. Sharing: Sure, I will share, but currently I am still learning and trying to get things running without flaws. |
Thanks - the IDE should always use the new version - everything's set to work without caching (it should work). The only issue is if you have enabled 'offline mode' in which case it'll always work from the cache of offline modules that it downloaded. |
This reverts commit ebcb304.
When dealing with the Quectel BG96 radio model, common practice is to register for the unsolicited return code
+QIURC
using the AT module. As soon as this URC is received, a callback function is called that is used to read out the actual data from the peer.An example URC might look as follows:
\r\n+QIURC: "recv",0,4\r\n1234
This means, 4 bytes where received from the peer and the bytes are 1234
But if you call
at.getData()
to actually read out the data, you get:\n123
instead of1234
So there is obvioulsy a bug in the code that doesn't eliminate the garbage newline character '\n'.
I attach a JavaScript script that can be used to reproduce this bug. The output of this script is as follows:
at-bug-test.js.txt
The text was updated successfully, but these errors were encountered: