[RFC] Extended data mode

[MathiasKoch]

Relevant links:

• https://github.com/u-blox/extended-data-mode-example-application-py/blob/b2cffee087987b69c81a0e88e7d7ea5aac33b3d8/edm.py#L139
• https://www.u-blox.com/sites/default/files/ExtendedDataMode_ProtocolSpec_%28UBX-14044126%29.pdf

[unizippro]

Motivation

In order to send data via open connections, the library has to support Extended Data Mode. Which at this point is not supported by the ATAT library.

Proposed Solution

Modify the ATAT library to support EDM. By enabeling the use of custom response code and error code matchers as worked on in https://github.com/BlackbirdHQ/atat/issues/42.

It also comes with a few other hurdles to overcome.

• ATAT only supports commands up to lenght 256.
• ATAT has some hardcoded standards for digesting AT commands
• EDM does not support ECHO as far as i can see. Which is important for changing reciver state in ATAT

Alternatives

An alternative would be to add an interpreting layer in front of ATAT in the event making it compatible with EDM causes too many problems. Another alternative would be to use the code from ATAT and build a custom library for ATAT+EDM

Implementation steps

[unizippro]

Update to solution

An update to the proposed solution.

Motivation

The former solution was on further inspection not possible without an extensive rewrite of ATAT. The idea of a interpreting layer would be good if not for the trouble of also having non-AT communication over the same stream, necessitating the excistance of a way to send around the ATAT library.

Proposed Solution

Write an EDM library. This will build upon the traits from ATAT in order to use those for parsing of commands, responses and URCs.

Implementation steps

• [ ] Implement parsing and recognizing AT commands responses and URCs
• [ ] Implement sending and receiving AT commands
• [ ] Implement sending and receiving socket data