Модуль отправки SMS IOT-GA6-B, который ранее стоил копейки, - теперь стоит 1к+ (и это на алиэкспрессе) и имеет очень мало лотов продавцов. Пришло время отомстить не заработавшему тогда модулю SIM800L (месть подают холодной, спустя 5 лет) - и заставить его работать на платформе Arduino: стоит 210руб, сильно распространён, куча примеров в интернете (правда, неверных - и даже опасных), не требует сторонней библиотеки, меньше ресурсов жрёт.

Читать эмоциями и голосом сержанта Дорнана, с примерным пониманием ответов модуля, - который, в итоге, сдался и заработал. Для ЛЛ, желающих ознакомиться только со схемой и исходниками, - сразу ссылка на архив.

Электроника, как хобби, практически перестала существовать: то, что раньше стоило 4к при самостоятельной сборке, - сейчас, условно, стоит 10к. И чел, хотевший поставить себе защиту от протечек, смотрит. Покупные в РФ стоят дохрена - лесом. Покупные в Китае стоят дёшево, но имеют такой же ограниченный недостаточный функционал, как в РФ, - лесом. Самодельная - хм, 10к, надо подумать - но печатные платы за 700руб/5шт в РФ больше не изготавливают, да ещё и за модуль 1к отдай, - тоже лесом.

Ну и остаётся хотя бы цену модуля отправки SMS с 1к+ до 0.2к уменьшить, чтобы хоть как-то спасти своё детище. Но нужно понимать: это засада. По модулям отправки SMS: интернет пестрит статьями, примерами, исходниками вида "у меня всё работает!" (в т.ч. теоретических). А, по факту: чтобы заставить работать модуль - нужно делать именно ювелирную работу: рыть даташиты микроконтроллера и чипа SIM800L, понять логику работы UART в контексте соединения их между собой (чтобы он не сгорел после нескольких часов/дней работы), определить алгоритм проверки правильности присоединения информационных проводов, определить правильные команды отправки и получения данных, научиться бороться с помехами. И если хоть в одном месте ошибёшься - модуль работать не будет. Справился за 2 дня - но это ещё не конец: помехи душат - нужны средства посложнее, чем пара подтягивающих резисторов, на что и будет потрачен день 3.

В даташите на ардуино сказано, что цифровые каналы работают как логическая единица с амплитудой 5В. В свою очередь, в даташите SIM800 сказано, что TTL-логика Rx/Tx работает с напряжением 2.1-3.1В как логической единицей входной (V_IH - High level input voltage) и 2.4-2.8В выходной (V_OH - High level output voltage). Если использовать цифровые каналы ардуино при создании цифрового последовательного порта Rx/Tx для связи с SIM800 - модуль надо защищать от превышения напряжения на 61% от максимального.

Выход Tx 5В ардуино является входом Rx 3.1В для SIM800 - превышение - заимствуется делитель напряжения из интернета 1кОм/10%+1.2кОм/10%. Напряжение получилось 2.764В при теоретическом диапазоне 2.48-2.74В - укладывается для обоих норм TTL модуля. И даёт возможность почти никогда не потерять логическую единицу, если напряжение вместо 5В станет 4В (как было при случайном питании платформы от USB-кабеля 3м без адаптера питания), - только если будет сочетание 11кОм и 10.8кОм: 1.98В.

Вход Rx 5В ардуино с усмешкой сожрёт 2.8В от Tx модуля. А вот преобразует в логическую единицу или нет - пока затык: в даташите минимум V_IH - 0.7V_CC - 3.5В. Это может быть причиной возникающих помех сейчас: не исключено, что нужен повышающий преобразователь TTL. Некоторые пишут, что повышали напряжение на модуле до 5В, - это повышает логическую единицу на Tx модуля - возможно, поэтому и начинает работать.

По аналогии с ардуино: если напряжение на модуле будет ниже нормы - его логическая единица начнёт опускаться - и вероятность ошибочного интерпретирования платформой возрастёт ещё больше. В даташите напряжение 3.4-4.4В - выставил с помощью понижающего преобразователя LM2596 3.9В (реализация питания модуля от USB: у него как раз 2А на выходе возможны, по аналогии с повышающим XL6009 в шуруповёрте). Если предполагается управлять модулем с помощью транзистора - обязательно ставить после модуля, к земле.

Итак, напряжение подано - модуль успешно часто мигает красной лампочкой, т.к. в нём нет SIM-карты. Модуль может обмениваться данными с Arduino и без неё - но нужно помнить на будущее: пидоры из МТС блокируют передачу данных, если симка оказывается не в телефоне и не с дорогим тарифом "для умных устройств", билайн работает через жопу, т-мобайл не имеет 2G - вообще работать не будет. Только мегафон обеспечивает корректную работу модулей отправки SMS без абонентской платы.

Время подключать модуль к платформе. Припаяли Rx к делителю и Tx к Rx платформы - и всё? А вот драйверпаком вам по астре:

- нужно быть уверенным, что платформа не подключена именно к ноутбуку именно с корректно работающим блютусом. Блютус блокирует единственный COM3 ноутбука - и к Arduino становится невозможно обратиться навсегда (блютус не вычищается до конца). Отсюда кабель USB 3м и взялся: до стационарного ПК тянуть пришлось, у которого этих COMx как грязи;

- когда работал с I²C, на практике: если не припаяешь подтягивающие резисторы на питание модуля, рассчитанные по определённой формуле, - даже если всё правильно спаял, работать не будет. В целом, подтягивающие резисторы - это добро: если изучается какой-то новый интерфейс - обязательно надо начинать с этого. Собственно, про интерфейс UART речь и идёт: в даташите нет информации - только Figure 21-23, в которых лишь косвенно заявлены 10кОм (потому что непонятно, что есть модуль и что есть клиент). Срабатывает везение - на каком-то форуме вижу другой контроллер и картинку, где подтягивающие резисторы Rx и Tx на питание имеют номинал 150кОм. А у меня таких временно нет - пришлось припаивать 2шт 10кОм к 3.9В. И вот если бы их не припаял - всё остальное было бы уже не важно: не заработало бы;

- какие исходники для тестирования выбрать - а никакие: пришлось сшивать Франкенштейна из говна и палок.

Общие положения:

- создаётся цифровой последовательный порт (#include SoftwareSerial.h"); SoftwareSerial SIM800(Rx, Tx);). Сразу получаете по зубам: комментарии к исходникам такие классные: "//Rx и Tx" - чьи??? Первое число - Rx платформы, второе - Tx платформы. И, конечно же, нельзя использовать D0 и D1: UART для общения именно с ПК идёт через них;

- настройка обычного и цифрового последовательных портов на одну скорость работы в бодах (Serial.begin(9600); SIM800.begin(9600);). Здесь нужно понимать, что оба порта могут работать на разных скоростях, равно как и модуль, равно как и окно монитора последовательного порта платформы, - и все 4 числа должны совпасть. Но как ты введёшь команду режимов работы модуля "AT+IPR=?" в модуль, если он не настроен, - вот и начинается у пользователей возня: перебор всех скоростей, потому что купленный модуль, внезапно, работает только на 115200;

- но скорость передачи не влияет на SIM800.available(). Даже если данные передается 1 символ из 1млн или передаются с жуткими искажениями - она покажет true не 0 в случае, если пины Rx и Tx подключены правильно;

- опытным путём выяснилось, что если послать в setup() SIM800.println("AT"): в loop() Serial.println(SIM800.read()) выдаёт какие-то цифры (мусор - уже не пустота). Замена на Serial.write стала показывать кракозябры. Но, с какой-то попытки, внезапно: среди них появилось корректное слово (то есть, скорость обмена данными - одинакова у всех и корректна, а не иллюзорно неверная);

- с этого момента - начинается дебаг программной и аппаратной части. Всё, что было до этого: лишь прелюдия и подготовка - дальше начинается фирменный треш, и готовьтесь орать голосом Дорнана.

Далее удалось найти такую конструкцию из левых исходников, которую вкурил только на следующее утро.

Происходит флешбек ~29-летней давности, когда 2 ПК соединяли школьниками по COM-портам. Ну кому знания прошлого века по такой устаревшей фигне, как устройство COM-порта, может пригодиться? Ардуинщикам: потому что делать платформу на COM-порте, работающем по USB, - это дёшево (и представьте лица людей возрастом <30, столкнувшихся лицом к лицу с этой дремучестью):

- сначала нужно напихать кактусов за воротник написавшему код. Available - это не булева доступность COM-порта, а количество байтов, которые пришли в его входящий буфер и ещё не были считаны. Когда в setup() begin'ами выставлены скорости, и эта дрянь находится в loop(), - ты получаешь возможность управлять SIM800, вводя вручную данные в окошке монитора COM-порта платформы;

- NL (новая строка) - обязательная настройка окошка COM-порта;

- (сам запутался, бл) вводишь команду в окошко - Serial Принимает её из окошка во Входящий буфер (как выводится Serial.print/write(что-то): что-то - вошло в буфер - отобразилось на экране). Serial.available>0 - послать эту-самую команду как сырые бинарные данные в исходящий (невидимый в исходниках) буфер mySerial (SIM800) - при этом входящий буфер Serial очистится (но надпись останется в окошке) - цикл loop() завершается. В последующих циклах входящий буфер Serial всегда пустой (если не вводить ещё команды), а входящий буфер ОТ SIM800 (видимый) наполняется информацией-ответом на команду. SIM800.available сработает после первого же поступившего байта (может хранить в себе не больше 64 символов) - записать в Serial эти данные, очистив таким образом входящий буфер SIM800 (и напихав в Serial (куда именно???)). По сути: пришёл 1 байт - надо читать - читается-очищается посимвольно.

Автор 4 строк, убейся об стену, бл!.. И эта дрянь - в каждом 4-м исходнике-примере интернета есть, без нормального описания. Опять же: этот 4-строчный код - тест модуля (с возможным удобством использования, но с полным неудобством понимания: даже программный println с ручным вводом из монитора смешаны в одну кучу), его не приспособить под реальные задачи. Точно так же: датчик протестируют какой-нибудь - а про то, что ему мозговзрывной преобразователь изобрести надо для реального применения, - молчок - изобретать приходится самому). Ещё бы в низкоуровневое программирование погрузил. MOV AX,CX, якорь мне в ESI...

Дальше - прикол похлеще. До корректных и понятных исходников - продолжилась работа с этими 4 строками, и были отпаяны подтягивающие резисторы на 3.9В. И всё, нет обмена. Только ночью приходит понимание, что и исходящей команды тоже не было видно в мониторе порта. То есть, модуль возвращает и посылаемую команду, и результат её отработки. Это же подтверждается временем с точностью до миллисекунды при выведении информации в монитор порта (на тех скринах в интернете, где галка стоит "Показать отметки времени"). Значит, когда пишешь команду в мониторе порта - она во входящий буфер помещается, а на экран не выводится, - левые исходники опять сбивают с толку. Write - выводит на экран. Read скрытно читает из буфера, очищая его.

Далее начал бомбить модуль командой "AT+IPR=?", получать ответ о возможных в использовании модулем скоростях. Снижение бод до 1200 - уменьшает количество помех. Однако это тот случай, когда уже никак аппаратно от помех избавиться не удалось, - сейчас надо возвращаться на 9600бод и при возможности обеспечить защиту от помех и при 115200-460800бод. Также важно: помехи могут кратковременно отсутствовать - удалось единично получить в ответе "AT" и "OK" чистенькими. Это ловушка: при тестировании модуля его нужно бомбить длинными запросами типа IPR, чтобы информации приходило много. И отправлять команду можно длинную: несколько println помещают во входящий буфер сразу несколько команд - модуль будет выполнять их после разового посыла (но в разном порядке - что ещё добавляет проблем при анализе: проблема оказалась в отсутствии delay). Работа при 9600бод и 1200бод соответственно, а также посыл разом 3 AT и получение 3 ответов на них (неизвестно, какой ответ к какой AT относится).

А также посыл 1 AT именно с println и получение 3 ответов (рисунок не сохранил - но это видно на самом-самом первом скрине статьи: много OK) - эти 4 строчки кода некорректно работают, если напишешь несколько println в setup(), - не надо было скрещивать ежа с ужом как работа с модулем через монитор порта и через println одновременно.

Начал долбить из монитора порта командами AT. 4-строчный говнокод отрабатывает корректно (становится заметно, что проблема не в передаче в модуль, а в приёме из модуля (исходящая команда искажается в ответе - но приходит чётко правильное количество символов). Значит, вероятность, что уровень Tx от модуля надо повышать, - увеличивается.

Корректировкой подтягивающих резисторов на 3.9В и работой с Tx - точно не ограничится. Когда покупается модуль, что на алиэкспрессе за 200руб, что в РФ за 1880руб в сраном чиподипе, - вы получаете его OEM. Ни версии прошивки модуля, ни номинала питания V_CC - на нём никакой информации, позволяющей зацепиться за его схемотехнику, обвес. А даташит - на чип, а не на модуль. Поэтому неизвестно, от 5В он работает (производитель учёл свои прошлые ошибки) или от 3.9В. Вы обязаны первоначально собрать делитель напряжения и подать на модуль 3.9В - нет возможности отказаться от этого дополнительно покупаемого обвеса. Как в IOT-GA6-B: якобы, рассчитан на 5В; а информационные пины - хрен, и паришься с ними потом, излишки напряжения резисторами гасишь.

Замена подтягивающих резисторов - непростая задачка:

- даташит платформы говорит об RST: "Pull-up resistors on the dW/(RESET) line must not be smaller than 10k". Но это для 5В - его надо пониже пересчитать для 3.9В?;

- замена 10кОм на 1кОм привела к неработоспособности передачи. Действительно, если смотреть на ранее изучаемый I²C: это "two-wire serial interface". Значит, для UART могут действовать те же формулы и параметры: это же тоже Serial. Например, в I²C ток должен быть <3мА - а я что делаю с резистором 1кОм: породил 3.9мА - получите-распишитесь. И, значит: и на сечение проводника надо обращать внимание (меньше - лучше: ёмкость меньше), и на его длину (больше - хуже: ёмкость выше). А из этого следует, что при разводке на печатной плате - дорожки Rx и Tx нужно делать как можно уже, чтобы не заморачиваться с длиной. Итак, пересчитать номинал на ток <3мА?;

- пикантности добавляет Figure 21 даташита SIM800: для UART 3.3В - Tx модуля подтягивается 10кОм к питанию, а Rx модуля 10кОм к земле. И мне 10кОм, значит, повыше пересчитать на 3.9В? Что они там курят?;

- ну раз у такого гиганта, как ATmega, написано "не ниже", и I²C имеет определённую формулу расчёта, и даташит SIM800 крутится вокруг 10кОм. 12.9кОм - максимальный из возможных вариантов, однако больно здоровый для формулы I²C при f_SCL ≤ 100kHz, начинающейся с 1.66кОм для 3.9В (чрезмерно высокий резистор завалит фронт сигнала - что, скорее всего, без резисторов и происходит: аналогия гигантского тераомного сопротивления). Придётся тыкать пальцем в небо: 2кОм (ёмкость проводов Rx и Tx неизвестна - к верхней границе номинала не добраться - приходится прижиматься к нижней). А номинал 2кОм, в отличие от 1кОм (как, например, и 13кОм) - в наборах попадается редко - есть только 2.2кОм - вот они, погрешности полезли, - и деться некуда: 2 ходовых резистора по 1кОм на такое говно тратить - увольте;

- да, номинал 2.2кОм выбран правильно, универсально. Даташит - на чип, обвес - неизвестен. Модуль уже может преобразовывать Rx и Tx до 5В, если сам имеет питающее напряжение 5В. Поэтому минимум начинается с 1.54кОм: чтобы припаять подтягивающие резисторы - и вообще о них больше не думать;

- нет, номинал 2.2кОм выбран неправильно. Потому что использовалась формула <100кГц, а 460800бод - 460.8кГц. А, не, правильно выбран: там формулы одинаковые у нижнего предела;

- но чёрт знает, какой номинал правильный: может, при большой длине провода эти 2.2кОм всё завалят, а при коротком проводе - будут оптимальными. Невозможно сделать энергоэффективность в этом вопросе (хотя сам модуль неэнергоэффективный - что я эти миллиамперы считаю).

Что ж, помехи убрались после замены подтягивающих резисторов - общение с модулем полностью корректно (второй раз уже такие чудеса за последние месяцы: вот что подтягивающий резистор животворящий делает!). Но если вышло, что модуль оказался ещё капризнее, - есть ещё решение для Tx: использовать 1 канал TTL-преобразователя ("преобразователь уровня" на алиэкспрессе) с 5В до 3.3В (2-канальный 8-дырочный за 30руб: меньше каналов нет - обдираловка). Минимум логической единицы у Arduino 3.5В - если взять минимум 2.4В с модуля и пропустить через преобразователь с коэффициентом 1.52, получается подозрительно корректная величина 3.6В. А вот почему Arduino сейчас вполне устраивает то, что напрямую передаётся из Tx модуля амплитудой не выше 2.8В (а 2.4В вообще ниже половины), - непонятно.

Итак, пришло время рисовать правильную схему подключения SIM800L к Arduino? Нет: надо поиграться с пинами. Пины с PWM на картинке - тоже принимает. А вот после 19200бод - перестаёт отвечать. Значит, опять возвращаемся к номиналу резистора. Но перед этим, для страховки: питающее напряжение на LM2596 выставить не 3.914В - а ровно 3.900В с помощью APPA 505 (мало ли). Без задней мысли, припаиваю 3.5кОм фактические - полностью перестаёт работать 19200бод, а 1200бод притормаживает (в обратную сторону надо). Поставил 1.35кОм - нормально, но опять не работает выше 19200бод. А потом выяснилось: 2.2кОм - правильный резистор (и, судя по 1.35кОм рабочему - с запасом), а SoftwareSerial на Arduino Uno/Nano - нестабилен на скоростях выше 19200бод. Всё... Теперь можно рисовать электрическую схему.

Хотя нет. Ещё можно сделать энергоэффективным и универсальным делитель на Tx платформы. Наступило время этот делитель подправить (и номиналы, и токи): 10кОм/10% и 15кОм/10% - максимум 3.01В при 5В с ардуино и минимум 2.2В при 4В с ардуино: при максимальных отклонениях резисторов в негативную сторону - укладывается в трубку 2.1-3.1В. Это даёт возможность уйти от вопроса недостаточного питания Arduino. Хотя, на данный момент в ардуино приходят 5В с погрешностью сотых вольта: даже через передок USB и кабель 3м - потому что вентиляторов нет, жрущих много десятков миллиамперов (как было со случайным экспериментом с охлаждением стенок холодильника). Спаиваю делитель - не работает: токи слишком слабы. При этом, делитель 1кОм и 1.5кОм - работает нормально. То есть: те, кто в интернете делители делали из 10кОм и 12кОм, - сами себе злобные буратины: по краю ножа ходят. Вот тебе и энергоэффективность... Действительно: если UART близнец I²C - то делитель 2.5кОм порождает для него приемлемый ток 2мА, а вот 200мкА уже как-то жиденько выглядит.

Ну хотя бы теперь можно нарисовать электрическую схему?! Рано: надо создать на Arduino пониженное питание 4В, как стресс-тест. Для этого спаиваем вместе A0...A2 при норме 20мА/канал - и питаем напрямую вентилятор 12В/0.25А (который при 5В жрёт 64мА: точно мощнее своих собратьев). Напряжение на Arduino опустилось до 4.5В (больше не вышло) - связь нормальная. А сейчас можно? Рано: надо с TTT-преобразователем протестировать что с 4.5В на ардуино, что с 5В (ещё и захватить напряжение питания 4.4В для модуля - да и 3.4В бы посмотреть).

При повышении до 4.4В - преобразователь LM2596 вежливо послал, выставив только 4.27В, - связь неисправна при 4.5В и при 5В на ардуино. При понижении до 3.4В - нет связи. Потому что провод Rx модуля от делителя оторвался - всё заново. При повышении до 4.27В: работает и при 4.5В, и при 5В, - но тормозит после появления монитора порта несколько секунд (сначала не отвечает, потом отвечает всегда). При понижении до 3.4В: шустро при обоих напряжениях платформы. То есть, повышенное напряжение для модуля - не торт, а в интернете люди до 5В задирают и выше.

С TTL-преобразователем - работал впервые. Оптом по каналам - дешевле: 8-канальный 20-дырочный стоит 61руб (TXS0108E). NoName 2-канальный со светодиодом - отстой: слишком яркий. На плате TXS0108E написаны диапазоны большого и малого питающего напряжения: 1.65-5.5В и 1.2-3.6В. Ну и применил к NoName: припаял +5V и +3.3V от Arduino (земли же общие - какая разница, откуда 3.3В придёт). Пуск в самой экстренной ситуации (4.5В на платформе - минимальная величина логической единицы, 4.4В на модуле - максимальная величина) - норма. Потом приходит понимание: 3.3В на TTL больше максимума 3.1В модуля - казалось бы, не хватает диода для поглощения излишка. Но выяснилось, что Rx всегда движется в 1 сторону, и Tx всегда в другую: Rx на платформе настроен на вход, гигантское сопротивление - в обратную сторону в модуль по TTL ничего никогда не прилетит. А это значит, что UART - не клон, а брат I²C: в I²C используется одна линия SDA для передачи в обоих направлениях (вторая SDL - "самоконтроль" "ACK/NACK").

Как понять, что работает TTL. Прицепиться мультиметром к TXD и земле модуля - увидеть холостые 2.883В. Потом подключиться к Rx платформы и увидеть 4.761В - коэффициент 1.65 получился (вместо 1.52, как задумывалось). Скорее всего, это связано с питанием платформы 4.5В (продолжаются стресс-тесты с недостаточным питанием).

Неясно, что делать с RST модуля: подтянуть бы куда; но куда и на что - непонятно. ИИ заявляет, что он уже подтянут к питанию через 10-100кОм.

Важная выдержка из даташита (но лишь рекомендованная, особенно при подключении к аккумулятору). Также выяснилось, что даташиты бывают разные: пользователь на форуме уверял, что взял резистор 1.2кОм, - а в моём даташите упоминания "1.2" по сопротивлению вообще нет.

Ну и как это всё с пониженным напряжением Arduino 4.5В выглядело: с вентилятором и TTL-преобразователем.

Симка вставляется металлом вниз, уголком сзади - до щелчка. Проверка - AT+CPIN?, вернёт "+CPIN: READY", даже если нет сети. А сеть модуль поймал спустя секунд 10 даже без антенны - и стал мигать редко.

Теперь нужно сделать корректные исходники и отмечать особенности программной работы (с учётом изучения всего и вся - это происходит уже просто, а вот исходники в интернете - ну совсем не нравятся):

- возвращаясь к говнокоду из 4 строк - его всё-таки стоит оставить: функционал посыла команд из монитора порта он обеспечивает. Но в комментариях нужно подписать: не вникать в работу этого исходника, чтобы сохранить рассудок, - вбивай свои команды в монитор порта и не отсвечивай (а также положить список этих команд - однако нет нормальной таблицы с их описанием, придётся-таки пользоваться интернетом);

- модуль после каждой команды возвращает 2 ентера и "OK" в конце - символы, по которым можно судить об окончании передачи данных;

- команда "AT+IPR=?" возвращает "+IPR: (),(0,1200,2400,4800,9600,19200,38400,57600,115200,230400,460800)". Странная работа: 0 - это на самом деле кастрированное число 300: модуль спокойно работает с 300бод (хоть и лагает сильно: видно бегущий курсор и выводимые символы);

- если команда не AT - модуль не ответит, если написана с ошибкой - "ERROR". Но уже без 2 ентеров и "OK" (или 1 из ентеров не видно);

- проверка модуля без использования монитора порта для ввода команд - совсем простая получилась. SIM800.println("AT") - далее тупо SIM800.readString (она читает периодом, указанном в setTimeout()) - далее тупо вывести в монитор порта результат. Даже available не особо нужна: за назначенное время модуль не уложился - его проблемы; и плевать, когда он начал передавать данные. Вся вот эта возня с посимвольным чтением - имеет смысл только в том случае, если хочешь сэкономить время. Но как показала практика использования IOT-GA6-B: магнитные бури на Марсе, вспышки на Солнце, товарищ майор под диваном - всё замедляет работу с данными. И лучше перебдеть излишней по времени задержкой, чем биться за сэкономленные секунды;

- ну и, собственно, отправка SMS. SIM800.println("AT+CMGF=1") - явное послание, что нужно послать SMS в определённом формате (ответ - "OK"). SIM800.println("AT+CMGS=\"+791612345678\"") - адресат (ответ - ">"). SIM800.print("TeXt. Текст") - LN не нужно, иначе ентер в сообщение попадёт. SIM800.print((char)26) - символ, означающий окончание ввода информации (SMS начнёт отправляться). В это время можно периодически брать информацию из буфера модуля (хранит до 64 символов - будет перезатираться) - будет описываться процесс посылки. А можно вообще ничего не брать и тупо  setTimeout(60000) и SIM800.readString: в последних строках точно будет какой-нибудь статус отправки;

- если отправлять через Монитор порта: char(26) - Alt+26 (стрелка вправо почему-то) или Ctrl+Z - но ни 1 из вариантов не сработал: самая последняя операция для отправки SMS осталась... И модуль после этого зависает: ждёт этого символа - поэтому любые AT-команды обречены на игнор. И модуль нужно именно перезагружать кнопкой на RST: даже если выключить - при "AT+CPIN?" - он возвращает не просто "OK", а ещё "SMS READY". Где эта SMS хранится - хрен знает (скорее всего, модуль получает остатки питания от Arduino: 1.33В на пине Tx имеются). Т.к. кнопки нет - пришлось и Arduino выключать;

- модуль возвращает что-то похожее на счётчик SMS (где? В отправленных SIM?), в случае успешной отправки;

- не донатите - с неподдержкой русского языка разбирайтесь сами. "AT+CMGF=0" - не работает. "AT+CMGDA="DEL ALL"" - не работает;

- последняя подлянка: если входящий буфер не очищать - он после 64 символов прекратит в себя пихать - будут получены именно 64 первых символа, а не 64 последних. Всё это время всё было нормально, т.к. общая длина ответов не превышала 64 символа - сохранялось всё. А как 170 символов послал - сразу х... И не 64, а 65 символов получилось какого-то х... Значит, к сожалению, придётся-таки символы с помощью available по одному вылавливать;

- на 300бод "AT+IPR=?" выведет результат в readstring "+IPR: (),(0,1200,2400,4800,9600,19200,38400,57600,11" - 54 символа. Не потому что 1000мс не хватило: и при 10с такая же фигня. Если повторить команду дважды - опять только первые 54 символа. В общем, с размером буфера модуля - реально, непонятки, - придётся-таки символы с помощью available по одному вылавливать;

- в итоге, решил без available: setTimeout(1), for 1-1000: readstring и delay(1);

- скетчи занимают мало динамической памяти в устройстве: 14-16%.