Question

I'm working on the firmware of a device that is going to be connected to PCs using Bluetooth in serial port emulation mode.

During testing, I found out that modem-manager on Linux "helpfully" tries to detect it as a modem, sending the AT+GCAP command; to this, currently my device replies with something like INVALIDCMD AT+GCAP. That is the correct response for my protocol, but obviously isn't an AT reply, so modem-manager isn't satisfied and tries again with AT+GCAP and other modem-related stuff.

Now, I found some workarounds for modem-manager (see here and thus here, in particular the udev rule method), but:

  • they are not extremely robust (I have to make a custom udev rule that may break if we change the Bluetooth module);
  • I fear that not only modem-manager, but similar software/OS features (e.g. on Windows or OS X) may give me similar annoyances.

Also, having full control over the firmware, I can add a special case for AT+GCAP and similar stuff; so, coming to my question:

Is there a standard/safe reply to AT+GCAP and other similar modem-probing queries to tell "I'm not a modem, go away and leave me alone?"

Was it helpful?

Solution

(making an answer out of the comments)

In order to indicate I do not understand any AT commands at all (aka I am not a modem) the correct response to any received AT commands should be silence.


In order to indicate I do not understand this particular AT command the correct response should be ERROR.

Anything between will trigger implementation defined behaviour of the entity sending AT commands. Some will possibly give up right away while modem-manager apparently is set on retrying sending the command until it gets a "proper" response.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top