Друзья, помогите разобраться что за интерфейс передачи данных Starline

Всем добра! Пытаюсь произвести реверс инжениринг протокола передачи данных между сигнализацией Starline типа A93 и её оригинальным GSM модулем, который идет как доп аксессуар и вставляется на плату блока самой сигнализации. на вооружении имеется осциллограф, логический анализатор я только заказал с али, поэтому он будет позже.
Насколько я понял, обмен данными осуществляется по двум линиям (третий это GND). Надо полагать, эти линии это Tx и Rx. Знаю тут есть люди, которые опытные и разбираются в протоколах, может чего подскажете - в правильном ли направлении идут мои мысли. на что похож этот протокол или это чисто своя тема от старлайн? Как читать биты ( или там все же сформировано в байты), имеется ввиду если протокол похож , например на i2c, то реально ли использовать готовые наработки-библиотеки или же полностью придется писать свой код для чтения инфы и , для случая эмуляции GSM модуля, также и передачи инфы?
Цель всего этого, попробовать эмулировать оригинальный GSM модуль, создав свой.

Итак , зацепившись на обе линии двумя каналами осцилла, я подсмотрел как происходит обмен данными. Думаю, это не является USARTом. Похоже, что передача происходит по синхронизации, причем от оппонента. Собственно далее инфа на скринах:

вот кадр увеличен. Сигнализация начала передачу на GSM модуль

вот весь кадр целиком. Длина кадра , я так понял 80 бит.

вот скрин запрос и сразу ответ

ну и еще пару скринов

интересная схема (не I2C* , не SPI* , не UART)
выглядет как будто :

  • когда Starlink передает данные то указаная вами линия TX работает как Data а линия RX рабтотает как CLOCK
  • когда модуль отвечает , назначение (фунцкионал ) линий обмениваеться

* - линия clock всегда управляется мастером

А есть ли какие-нибудь способы понять, что в конкретной посылке передаётся?

в первых версиях 93 старлине с gsm протокол был свой ,
мы сперва хотели его разобрать , а потом смысл пропал… головняк еще тот.
У Вас временные интервалы в графиках не точные… хз почему.
Старт обычно начинался прижатием к 0 (У Вас синей линии , потом два строба начало передачи потом следовала команда и заканчивался либо просто поднятием линии , если ответ не нужен был , либо импульсом 250мкс , который переводил GSM в режим передачи, ждал непомню вроде 100ms и потом начинал тактировать чтение с GSM .

Не понимаю, зачем разбирать протоколы нижнего уровня. Передача может быть кодированной. Здесь иногда проблемы с высоким уровнем. Очень часто столько времени убивается. Ну расшифруете вы данную посылку, а она окажется временно зависимая. И даже если вы сформируете точно такую же посылку, ни чего не будет происходить. Я не говорю, что это так и есть, но может вы окажетесь везучим, и случится чудо.

я абсолютно также подумал. Но здесь, похоже тактирование задаёт принимающая сторона. Надо тест сделать. отключить линию Rx и посмотреть.

Ну попробуй, и расскажи.

Ну протокол предыдущего стандарта я расшарил. Возможно и этот получится. Это просто хобби

1 лайк

пока не могу. Надо почитать про i2c, SPI, особо не разбирался раньше как они работают . Почитав по диагонали, понял, что протокол немного похож на i2c.

способов нет. Заведомо известно только функция команды которую посылаем. Например. Отправляем на GSM модуль команду “поставить на охрану” и смотрим что на шине творится. Также при процедуре первоначальной привязки модуля к сигнализации, тоже можно заснифить, эту процедуру.
Сейчас у меня задача физику разобрать и стабильно 80 бит кадра принимать и тогда уже смотреть динамический или диалоговый ли там обмен. Сильно и как меняется по факту тело сообщения команды при отправке одних и тех же команд.

интересно , что при процедуре первоначальной привязке GSM модуля к сигнализации всего летит два кадра от сигналки к GSM. При этом GSM даже ничего не отвечает (ну только синхросигналом-меандром 80 бит). Соответственно видимо какая-то уникальная инфа при этом передается от блока сигнализации в GSM модуль. Он эту инфу запоминает и далее использует в последующих сообщениях. Кому интересно посмотреть снифф. вот простая программа осциллографа и файлы снифы

Нет, не i2c. Просто две линии - тактовая и данные.

Думаю, что для начала нужно определиться кто тактирует - инициатор или получатель.
Понятно, что оба конца держат ноги в инпуте. Кто хочет передать - поджимает дату. После этого начинается тактирование и посылка. Один такт - один бит.

SPI очень сильно отличается от I2C , в I2C есть машина состояний , в SPI этого нет в таком виде в котором есть в I2C

у меня в идентификации авто была система с открытым ключом,
тегу посылался некий случайный ключ, по которому тот кодировал свой код,
при периоде повторения запроса порядка 15с, код тега мог бы повторится примерно через 2 года. Вот и декодируй. Система стояла на объектах Сбербанка и ГУ ЦБ.

Если они применили на этом интерфейсе прицип диалогового кода, как это сделано в радиоканале брелока, тогда естественно, тут нефиг ловить. Ну а вдруг что то попроще. Будем надеяться… Скоро дальше потестирую

вытащил GSM модуль. (для инициирования каких то сообщений включил зажигание, при этом сигналка шлет в gsm новое состояние). Подтвердилось, тактирует принимающая сторона. Вот скрин без gsm модуля. Сигналка просто опускает линию в 0, пытаясь начать передачу, но ничего далее не происходит, т.к. тактирование не обнаружено.

На I2C сильно похоже, по крайней мере Start и Stop. Но вот с битами … как будто данные защелкиваются и по фронту и по спаду - и получается 80 бит. В I2C это было бы всего 40 бит.

сымитировал тактирование ардуиной пока простым скетчем на delay и передача от сигналки пошла. (GSM модуль сейчас не подключен)

#define RX 3
#define TX 8

void setup() {
pinMode (TX, OUTPUT);
digitalWrite (TX,1);
pinMode (RX, INPUT_PULLUP);
}

enum states {WAIT, CLOCK};

void loop() {
bool curRX = digitalRead(RX);
static bool state = WAIT;
static bool lastRx = digitalRead(RX);

 
 if (state == WAIT && lastRx != curRX)
  {
  if (lastRx && !curRX){
  state = CLOCK;
  delayMicroseconds (100);
  digitalWrite (TX,0);
  delayMicroseconds (40); 

  for (int i=0; i<81 ; i++){digitalWrite (TX, !digitalRead(TX)); delayMicroseconds (90);}
 state = WAIT;
  }
 lastRx = curRX;
 }
}

уже хорошо, успехов!

зы. несколько тире в след строке оказывается генерит жирный шрифт

О!
вот уже и успехи есть =)
набирать статистику теперь по состояниям получается надо