AT commands remotely through tcp?

Legacy Open AT
1

Hi,
Does anyone know how to issues AT commands remotely over tcp/ip?
Is this possible?
can we control the Q2686H through tcp the same way we can over serial port?
Thanks.

2

Hi elef,
You mean that you want the WCPU can execute the AT commands which received via tcp/ip connection. If yes, you can do it by OpenAT and WIP.
ttt

3

Take a look at the ADL User Guide: there is a section on how to issue AT Commands and receive their responses in Open-AT…

Well, it can never be quite the same, can it?
There are certain restrictions - again, look at the ADL User Guide

4

This Lua program, taken from the samples IIRC, does it for you:

TCP2AT_SERVER_PORT = 2008

function read_loop (sock)
   -- Callback to clean upon TCP error / shutdow:
   sighook (sock, {"error","peer_close"}, function() sock:close() end)
   -- Infinite execution loop, broken by TCP error / shutdown:
   while true do
      local line = sock:read "*l"         -- Read a line from socket (may block)
      line=line:match "(.-)[\r\n]*$"      -- Get rid of '\r' and '\n' chars
      local resp = at (line)              -- Execute it, receive response lines
      sock:write(table.concat(resp),"\n") -- Concatenate and write back result lines
   end
end

-- Launch the server
at_socket = wip.tcp_server( TCP2AT_SERVER_PORT, read_loop)

It’s multithreaded, so it supports several concurrent TCP connections and doesn’t mix up commands and responses.

5

yes actually i havent looked into Lua yet.
but that code you posted, now that i think about it, is quite similar to do in C.
i can keep reading a line from the tcp socket, then send it to an AT handler and just send the response back to the client. not as simple, but shouldnt be overly difficult either. (apart from few technicalities with the AT response callback handler so it doesnt mix up the responses with multiple clients).
Thanks.

6

Indeed, you’ll have to deal with non-blocking ADL APIs, commands and responses buffering (or at least protection against buffer overflows), cutting user commands into lines, data flow control when AT command responses and TCP throughput don’t match (that’s usually tricky to debug, because it’s difficult to simulate all cases), not mixing up several clients…

Plus all of the challenges that will be raised by features you might eventually have to add: authentication to prevent rogue accesses, IP bearers control, maybe an emergency access / bearer setup through SMS…

Given the non-realtime nature of both AT commands and IP over GPRS, I can’t see a good reason to pay C debugging and maintenance times, but good luck :smiley:

7

yer i totally agree, not worth the time and effort. i was merely asking incase there was a quick way in c or maybe it was already part of the OAT.
looks like my “few technicalities” comment needs to be modified to “lots of technicalities”
hehe
thanks.