RW9UAO
исследование оранжевого ВЧ модуля, прошивка v1 (глючная)

получив модули в подарок от DL7RFP, решил поиграться с ними. прицепил к “турниге” с прошивкой er9x, приемник AR8000.
для начала я прицепил граббер к SPI порту CYRF трансивера. проводил захват в честном режиме BIND, перед каждой новой попыткой менял ID передатчика удерживая кнопку “change ID”.
описание пакета: первые 8 байт - повторенный два раза manufacturer ID, 0x0A - количество каналов (я выбрал в пульте 10, с большим не заработало), 0хВ2 - тип передатчика (dsmX, 11 ms)
вот что я увидел:
попытка 1 - 0x3A, 0x63, 0xAA, 0xC5, 0x3A, 0x63, 0xAA, 0xC5, 0x05, 0x88, 0x01, 0x0A, 0xB2, 0x00, 0x06, 0xD2
попытка 2 - 0x3A, 0x64, 0xAA, 0xC5, 0x3A, 0x64, 0xAA, 0xC5, 0x05, 0x8A, 0x01, 0x0A, 0xB2, 0x00, 0x06, 0xD6
попытка 3 - 0x3A, 0x65, 0xAA, 0xC5, 0x3A, 0x65, 0xAA, 0xC5, дальше не интересно уже
попытка 4 - 0x3A, 0x66, 0xAA, 0xC5
попытка 5 - 0x3A, 0x67, 0xAA, 0xC5
попытка 6 - 0x3A, 0x68, 0xAA, 0xC5
попытка 7 - 0x3A, 0x69, 0xAA, 0xC5
попытка 8 - 0x3A, 0x6A, 0xAA, 0xC5
попытка 9 - 0x3A, 0x6B, 0xAA, 0xC5
попытка 10 - 0x3A, 0x6C, 0xAA, 0xC5
попытка 11 - 0x3A, 0x6D, 0xAA, 0xC5
попытка 12 - 0x3A, 0x6E, 0xAA, 0xC5
попытка 13 - 0x3A, 0x6F, 0xAA, 0xC5
попытка 14 - 0x3A, 0x70, 0xAA, 0xC5
попытка 15 - 0x3A, 0x71, 0xAA, 0xC5
попытка 16 - 0x3A, 0x72, 0xAA, 0xC5
дальше надоело.

в заголовке пакета с данными используется только два последних байта. в режиме дсмХ это как бы пофигу, там номера используемых каналов рассчитываются на основании всех 4-х байт и пересечение мало вероятно, а вот в дсм2 может случиться неприятность. если только Оранжи не вычисляют пару рабочих каналов на основании первых двух байт manufacturer ID.

постараюсь ответить на поставленные вопросы.

  • is Orange ID unique?
    и да и нет. нужно раз 50 нажать на кнопку “change ID” и использовать только dsmX приемники. инструкция прямо говорит о нужности смены ID, значит он прошивается один на все модули. постараюсь проверить еще один ВЧ модуль.
    yes and no. you need 50 times to press the “change ID” button and use only dsmX receivers. user manual directly speaks about being wanted change ID, so he burn one for all modules. try to check out another RF module.

  • is the module reflashable?
    естественно. для работы с Xmega32a4 я собрал себе набор инструментов code.google.com/p/orange-tx-module-dsmx/…/list
    yes. use any tools. i build firmware for usbasp programmator and avrdude with Xmega support.

  • can the TX-part be used as the original Spektrum unit for modify TX?
    не понял вопроса.
    do not understand the question.

  • what changes if you press the ID button 3-times short?
    выглядит как ничего.
    look like nothing.

разобрался с методом шифрования валкеры

итак. хочется для какой-нибудь поделки сделать модификацию, например, написать свой софт для мелкого квадрика, добавить привязку к спектруму. но существует шанс свой софт не дописать, а родной угробить. валкера выкладывает прошивки для некоторых своих поделок. например, для моей “new v120d02s” есть обновление прошивки. но они зашифрованы. а bootloader мы уже потерли своими экспериментами и не можем прошить зашифрованный бинарник. решил я на досуге посмотреть чего можно сделать.
смотрим в шифрованный бинарник, в начале файла много повторяющихся байт. это JMP table. значит файл зашифрован слабо.
внутри стоит хмега32а4, собираем компилятором winAVR любой код под этот процессор. в начале бинарника идет таблица JMP для прерываний. т.е. если примем байт в УАРТ, то процессор сделает переход по этой таблице.
первые байты представляют из себя jmp _reset_vector, который ведет в код начальной инициализации. остальные, если вектор не используется, то по идее тоже на вектор сброса. смотрим код и рядом дизасм его:

00: 0C 94 BC 00 jmp 0x00BC
02: 0C 94 DD 00 jmp 0x00DD

теперь смотрим в шифрованный бинарь, видны повторяющиеся строки в jmp table. предположим, что используется обычный оператор XOR, получим начальные байты ключа. т.к. первые байты команды будут гарантировано 0C 94. адреса пока оставим как есть. сделаем допущение, что адрес будет состоять из одного байта, старший байт нулевой. наполняем табличку которой будем построчно XOR файл.

unsigned char XOR[16]={0x89, 0xc7, 0, 0xb4,    0xdf, 0x65, 0, 0xa1,   0xb7, 0xca, 0, 0x0c,     0x70, 0x33, 0, 0xba};

дизассемблируем полурасшифрованный бинарник. таблица переходов расшифровалась, но адреса пока в виде мусора и часть команд в виде мусора. значит идея работает. надо получить остаток ключа.
смотрим в код сгенереный компилятором. точнее в точку куда ведет jmp reset_vector
это известный мне файл

+000000BC:   2411        CLR       R1             Clear Register
+000000BD:   BE1F        OUT       0x3F,R1        Out to I/O location
+000000BE:   EFCF        SER       R28            Set Register
+000000BF:   E2DF        LDI       R29,0x2F       Load immediate
+000000C0:   BFDE        OUT       0x3E,R29       Out to I/O location
+000000C1:   BFCD        OUT       0x3D,R28       Out to I/O location
+000000C2:   BE18        OUT       0x38,R1        Out to I/O location
+000000C3:   BE19        OUT       0x39,R1        Out to I/O location
+000000C4:   BE1A        OUT       0x3A,R1        Out to I/O location
+000000C5:   BE1B        OUT       0x3B,R1        Out to I/O location
+000000C6:   E211        LDI       R17,0x21       Load immediate
+000000C7:   E0A0        LDI       R26,0x00       Load immediate
+000000C8:   E2B0        LDI       R27,0x20       Load immediate
+000000C9:   E2E0        LDI       R30,0x20       Load immediate
+000000CA:   E0FF        LDI       R31,0x0F       Load immediate

это то что дизассемблер сделал из полурасшифрованного файла

+000000E2:   1A7F        SUB       R7,R31         Subtract without carry
+000000E3:   7232        ANDI      R19,0x22       Logical AND with immediate
+000000E4:   2411        CLR       R1             Clear Register
+000000E5:   BE40        OUT       0x30,R4        Out to I/O location
+000000E6:   EFCF        SER       R28            Set Register
+000000E7:   E266        LDI       R22,0x26       Load immediate
+000000E8:   BFDE        OUT       0x3E,R29       Out to I/O location
+000000E9:   BFEB        OUT       0x3B,R30       Out to I/O location
+000000EA:   BE18        OUT       0x38,R1        Out to I/O location
+000000EB:   BE3F        OUT       0x3F,R3        Out to I/O location
+000000EC:   BE1A        OUT       0x3A,R1        Out to I/O location
+000000ED:   BE44        OUT       0x34,R4        Out to I/O location
+000000EE:   E212        LDI       R17,0x22       Load immediate
+000000EF:   E019        LDI       R17,0x09       Load immediate
+000000F0:   E2B0        LDI       R27,0x20       Load immediate
+000000F1:   E3C2        LDI       R28,0x32       Load immediate
+000000F2:   E6F1        LDI       R31,0x61       Load immediate

опа, среди мусора нашлись похожие команды, ведь кроме части таблицы расшифровалась и часть кода. и даже команда CLR R1 видна. записываем адрес этой команды 0x00E4.
теперь поищем куда ведет переход с неиспользуемого прерывания. у нас это адрес 0x00DD

+000000D6:   3EAD        CPI       R26,0xED       Compare with immediate
+000000D7:   07B1        CPC       R27,R17        Compare with carry
+000000D8:   F7E1        BRNE      PC-0x03        Branch if not equal
+000000D9:   940E018B    CALL      0x0000018B     Call subroutine
+000000DB:   940C078E    JMP       0x0000078E     Jump
+000000DD:   940C0000    JMP       0x00000000     Jump
+000000DF:   94F8        CLI                      Global Interrupt Disable
+000000E0:   E8E1        LDI       R30,0x81       Load immediate

а вот в похожий код

+00000100:   F7E1        BRNE      PC-0x03        Branch if not equal
+00000101:   9428        SEN                      Set Negative Flag
+00000102:   29FF        OR        R31,R15        Logical OR
+00000103:   942A        DEC       R2             Decrement
+00000104:   2D7C        MOV       R23,R12        Copy register
+00000105:   9453        INC       R5             Increment
+00000106:   0000        NOP                      No operation
+00000107:   93B6        LAC       R27            Load and Clear
+00000108:   93DF        PUSH      R29            Push register on stack

в мусорном коде находим последовательность байт 94 через нужное нам расстояние, это очень похоже на то, что надо. и даже видим 00 00, это адрес куда будет совершен переход. записываем адрес этой команды, 0x0105.
дописываем адреса

00: 0C 94 E4 00 jmp 0x00E4
02: 0C 94 05 01 jmp 0x0105
04: 0C 94 05 01 jmp 0x0105
06: 0C 94 05 01 jmp 0x0105
08: 0C 94 05 01 jmp 0x0105

и так всю строку до конца. получаем оставшиеся ключи

unsigned char XOR[16]={0x89, 0xc7, 0x26, 0xb4, 0xdf, 0x65, 0x26, 0xa1, 0xb7, 0xca, 0x5f, 0x0c, 0x70, 0x33, 0xb9, 0xba};

обрабатываем зашифрованный файл и суем его в дизассемблер.
ага. таблица переходов расшифровалась, код куда ведут эти jmp тоже похож на скомпилированный. проверяем куда ведут jmp векторов прерываний, убеждаемся, что в начале этих процедур стоит много push register, а в конце pop register и IRET.
вуаля.
теперь код, которым надо зашифровать свой бинарник, чтобы встроенный bootloader его принял за свой:

#include <stdio.h>
void main(void){
FILE *fp_input, *fp_output;
unsigned char buffer[16];
//for 
unsigned char XOR[16]={0x89, 0xc7, 0x26, 0xb4, 0xdf, 0x65, 0x26, 0xa1, 0xb7, 0xca, 0x5f, 0x0c, 0x70, 0x33, 0xb9, 0xba};
int i, c;

fp_input=fopen("input.bin", "rb");
fp_output=fopen("output.bin", "wb");

for(i = 0; i < 1590; i++){
	fread(buffer, sizeof(buffer[0]), 16, fp_input);
	for(c = 0; c < 16; c++){
		buffer[c] ^= XOR[c];
	}
	fwrite(buffer, sizeof(buffer[0]), 16, fp_output);
}
fclose(fp_input);
fclose(fp_output);
}
оранжевый 7-ми канальный

разобрал оранжа с ХК, который с S-BUS
внутри стоит забавный проц NUVOTON M054LAN, 16К флэша, 4К оперативки и ядро ARM® Cortex™-M0
плата приличного качества, пайка хорошая, можно брать.

копаю ВЧ блок ДХ8


на ВЧ блоке ДХ8 есть следующее:


4 нога - картинка 3, 4 - явно SPI clk

5 нога


7 нога - картинка 5, явно SPI data - MISO/MOSI



9 нога - картинка 6, 7 явно SPI data - MISO/MOSI


12 нога - картинка 0


картинка 1 - 1 канал 5 нога, 2 канал - 7 нога(data), 3 канал - 9 нога(data)


картинка 2 - 1 канал 12 нога, 2 канал - 4 нога (clk), 3 канал - 5 нога



картинка 8 и 9 - 1 канал 7 нога(data), 2 канал - 9 нога(data). 3 канал - 4 нога (clk)

скорость на SPI иногда меняется. странно все это.
ссылки на фотографии
img-fotki.yandex.ru/get/…/0_70b4e_9e1affe1_orig
img-fotki.yandex.ru/get/…/0_70b4d_8ad7fc81_orig
img-fotki.yandex.ru/get/…/0_70b4c_264236d2_orig
img-fotki.yandex.ru/get/…/0_70b4b_110bea86_orig

цвета проводов copterX

блок ФБЛ, провода/разъем влево, светодиоды вниз.
провода сверху:
черный - масса
красный - питание
черный - элерон
красный - элеватор
белый - коллектив питч
провода снизу
черный - масса
красный - питание
белый - усиление гироскопа хвоста
желтый - хвост

Валька приехала

да уж. мысль с установкой коптерхФБЛ заманчивая, но что-то уже не кажется реальной. надо как-то закрепить, иначе канопа не налезает, а без канопушки летать будет не комфортно.
разобрал мозги валькины, все собрано на одной плате, вторая сугубо для защиты при краше и припаяна в 4-х точках.
Xmega32 - обычный процик
CYRF6936 - наш любимый трансивер.
MMA8452Q - I2C 3 оси аксель
ITG-3205 - I2C 3 оси гир
импульсный питальник на 3,3 в наверное. т.к. питание с аккумулятора идет напрямую через ESC.
схему пока не рисовал.
тут уже ломают deviationtx.com/…/824-walkera-rx-reverse-engineeri…
в общем есть три варианта: все же поставить свой фбл с приемником спектрума; сделать передатчик стандарта валкеры (купить готовый тоже можно, но этому мешает жабус вульгарис); сделать свою программу, бо я умею к спектруму привязываться, а вот ФБЛ софтину - надо думать, брать за основу какой-нибудь мультиви, и алга.

dsm2 tm1000

разобрался я с логикой работы ДСМ2 и телеметрии. нарыл кое-что в интернетах, товарищ один для валкеры серии дево пишет универсальную прошивку с поддержкой разных протоколв. при биндинге передатчик отдает 4-ре байта manufacturer ID + номер модели по порядку (это для фишки модел матч), приемник сохраняет эти 4-ре байта. при последующем включении передатчик ищет пару каналов почище и начинает там вещать. SOP и DATA берутся из таблички по некоторому закону на основе номера канала и ID. приемник при включении начинает сканирование каналов с аналогично выбранными SOP и DATA. также смотрит на совпадение сохраненного ИД и ИД пришедшего в пакете.
в общем сканирование я освоил, прием пакетов тоже, с содержимым пакетов разобрался. а вот передача пока не идет.

DSM2 нипанимайу

по ходу дела выясняется, что передатчик и приемник меняют пары каналов и SOP в ходе работы. вот типа так (захват SPI обмена происходит при включении питания):
забиндил, передатчик не выключал
канал 0x26, SOP A2 35 A2 D1 A2 FC A2 97 A2 23 A2 D4 A2 C9 A2 88
канал 0x32, SOP A2 40 A2 BA A2 97 A2 D5 A2 86 A2 4F A2 CC A2 D1
сменил модель, вернул предыдущую
канал 0x26, SOP A2 35 A2 D1 A2 FC A2 97 A2 23 A2 D4 A2 C9 A2 88
канал 0x32, SOP A2 40 A2 BA A2 97 A2 D5 A2 86 A2 4F A2 CC A2 D1 <- ошибка приема пакета
ресет, делаем новый захват, на передатчике ничего не меняем
канал 0x26, SOP A2 35 A2 D1 A2 FC A2 97 A2 23 A2 D4 A2 C9 A2 88
канал 0x34, SOP A2 9E A2 08 A2 D1 A2 AE A2 59 A2 5E A2 E8 A2 F0 <- канал и SOP сменились
выключаем передатчик, включаем
канал 0x21, SOP A2 35 A2 D1 A2 FC A2 97 A2 23 A2 D4 A2 C9 A2 88 <- канал сменился, SOP осталась
канал 0x4A, SOP A2 5F A2 30 A2 3B A2 56 A2 96 A2 45 A2 F4 A2 A1 <- канал и SOP сменились вааще

не, ну вот как жить? очевидно, что есть служебный канал, на который приемник и передатчик уходят при потере связи/выключении передатчика и там меняют себе настройки. надо курить дизасм и грабить SPI по ходу работы с целью отлова смены канала кроме текущих двух.

принимаю пакеты

что-то я делаю не так. процедура следующая:

  • заливаю прошивку оранжа
  • биндинг к передатчику, все в порядке, серва ходит за ручкой
  • считываю ЕЕПРОМ, перехватываю SPI поток от проца к трансиверу, получаю номера каналов и номера пары SOP/DATA
  • заливаю свою программу, которая инициализирует трансивер, заливает нужную пару CRC/SOP/DATA и встает на нужный канал.
  • идет прием двух пакетов, по обоим каналам. все нормально, вижу изменения на ручки.
  • переключаю модель в передатчике, прием пропадает. это нормально.
  • возвращаю модель ранее привязанную. приема нет. а вот это уже не нормально.
    че делать - х.з. надо раскуривать дизасм глубже, есть там пара моментов про служебный канал.
    перехватить SPI обмен в двух случаях - после бинда, до смена модели и после смены модели. вечером попробую.
всякости

после долгого перерыва вернулся к спектрум ДСМ2. самодельный самописный программатор для кипреса, что стоит в оранжах работает нормально и относительно стабильно. феерических глюков в PSoC билдере не обнаружил. пишу на С, но прийдется переходить на АСМ, ибо программа намечается большая, а С дает небольшой оверхед, но его много и рискую не влезть во флэшку.
вчера видел как 6-ти канальный оранж принимает 14 каналов. забавно. сателлиты вроде тоже умеют 14 каналов отдавать. после переключения модели прием пропал, как и ожидалось. при возврате нужной модели приема уже не было. что не ожидалось. странно все это. в ветке про ДХ7S обнаружили, что можно привязать одновременно два приемника =) странно =) как-же раньше-то кроме приемника привязывались еще и сателлиты, которые по сути тот-же приемник =) вот, привяжу одновременно два приемника и посмотрю. перехват SPI от проца в трансивер работает нормально и показывает мне какие два канала используются, и какие SOP/DATA пары используются. пока не понял как зависят номера SOP от номера канала.
у буржуев попадалась тема по добавлению пары-тройки каналов в ДХ8. там от центрального проца идет поток УАРТ на ВЧ модуль. так вот если в конце посылки из 8-ми пакетов добавить еще пару байтиков, то в приемнике будет щасте. но есть нюанс. надо ставить свой проц с коммутацией УАРТ потока и отслеживанием выключателей. надо подумать надо ли, и придумать какие выключатели отслеживать. свою прошивку для ДХ8 писать как-то не хочется =) если только купить за бесценок паленую/сдохшую на прошивке DX7S/DX8…
есть еще одна мысль. посканировать каналы, пары SOP/DATA привязанные к этим каналам мы знаем. в принимаемом пакете есть GUID (адрес передатчика). можно посмотреть, кто сейчас работает в эфире. а можно ведь еще и передачу включать в нужные моменты на нужном канале =) усилителей на 2,4 ГГц щас навалом =)
DSMX пока не ковырял. а было бы круто перешить оранжи в ДСМХ…

запчасти в наличии

новье:
подкосы - 2 комплекта
комплект тяг с линками - 1 шт
передний привод ремня - 1 шт
хвостовые лопасти - 1 комплект
башка в сборе с лидерсов золотистая - 1 шт
хвостовой кейс с ремнем (без цапф и прочего) - 1 шт
основные валы - 4 шт
вал хвостового ротора - 4 шт
межлопастной вал - 8 шт.
держатель хвостового оперения, металл - 1 шт
хвостовой слайдер с поводком - 1 шт
хвостовые балки - 4 шт
лопасти стекло с ХК - 3 комплекта
лопасти тяжеленный черный пластик - 1 комплект
250-й гироскоп - 1шт

полуживое
хвостовая балка после краша, относительно выровненная - 1 шт
хвостовой кейс с ремнем с люфтами в подшипниках - 1 шт
хвостовой слайдер с цапфами - 1 шт
лопасти стекло с ХК с плохой балансировкой - 1 комплект
лопасти дерево, битые, наверное на выброс - 1 комплект
лопасти стекло с лидерсов - 7 шт
головы на деффектовку - 4 шт
пакет с тягами с линками
сервы 933 б/у - 4 шт
целиком тушка в сборе без головы и мотора.

надо
шасси
основная шестерня
основной вал
вал хвостового ротора
нижняя пластиковая деталь рамы

Tags:
поножовщина оранжа

P0[0] - MISO CYRF6936
P0[1] - вход UART сателлита
P0[3] - SCK CYRF6936
P0[5] - MOSI CYRF6936
P0[6] - IRQ CYRF6936
P0[7] - SS CYRF6936

P1[0] - RUDD - DATA
P1[1] - AILE - SCLK
P1[4] - GEAR
P1[5] - ELEV
P1[6] - AUX1
P1[7] - THRO

P3[0] - LED
P3[2] - BIND

XRES - рядом площадка

программатор живет совсем

приделал к программатору загрузку бинарника по Хмодему. прошивка всех 8-ми килобайт занимает около минуты.
стирает, пишет, верифицирует. секурность не добавлял, забью на нее.
теперь надо собирать хелловорлд и заливать в таржет PSoC систему =) с дизайнером и юзер модулями более-менее разобрался, собирается и компилится без ошибок и варнингов. повыводил на ноги разную отладочную информацию, типа внутренних частот ШИМа и баудрэйт генератора. можно завтра залить, убедиться, что нифига не работает и успокоиться на этом.

Tags:
tm1000 inside

внутри телеметрийного модуля стоит ВЧ блок аналогичный ВЧ блоку передатчика. мощность 20,40 dBm или 110 мВт. печалько, что на нем экран, пока не отпаивал. о съеме протокола между процом ВЧ блока и трансивером пока речь не идет.
на второй плате стоит CY8C27443-24PVXI и 5209 в качестве питальника. PSoC принимает данные о битых пакетах с приемника по УАРТу, цифрует показания датчиков и в инверсном УАРТе гонит данные на ВЧ модуль. попутно на ВЧ блок идут еще какие-то странные импульсы. включение передачи что ли.
шина X-BUS похоже представляет из себя I2C. контакты идут на ноги 10 и 11 и подперты резисторами. к тому же в даташите на эти ноги повешен I2C.
ноги программирования PSoC выведены:
13 SCLK - разъем RPM
15 SDATA - разъем DATA
один светодиод на плате тупо подключен к УАРТУ и показывает поток данных от приемника.
ВЧ блок:
1 - масса
2
3 - питание
4
5
6
7
8 - масса
9 - от PSoC, -----U-------
10 - reset процессора ВЧ блока
11 - от PSoC, поток данных, ISSP-data
12 - ISSP-clock

программатор живет

запустил программатор. мега8 дрыгает ногами, использую ногу ресет кипреса, надо делать через управление питанием. ИД чипа читает, стирает все целиком, пишет страницу рандомным мусором, затем верифицирует страничку. все 128 страниц по 64 байта тест прошли примерно секунд за 20 =) надо прикручивать Хмодем для заливки бинарника через терминал - и алга!
жду оранжевый приемник для опытов.

Tags:
приехала DX8

тискаю. руки-крюки. все непривычно.
приемник и телеметрию пока не разобрал. там шестигранник 1 мм или даже 0,8 мм. зараза, у меня такого нету. сквозь полупрозрачный корпус видно, что ВЧ часть в блоке ТМ1000 накрыта экраном. ну и ладно, мне с него только УАРТ надо, а он на разъеме =)
в общем я рад =)

Tags:
приехали процы

приехали процики CY8C21334 в корпусе 20-ти лапом. развел монтажку по быстрому, завтра доделаю до ЛУТ и постараюсь вытравить. и буду играться с программатором самодельным. посмотрим как оно будет.

начал ковырять софт и документацию на cy8c21434

есть пара мыслей соорудить пару вещей из “оранжевых” приемников для спектрума. стоят они около 6-ти долларов, имеют на борту проц cy8c21434 и трансивер CYWUSB6934 либо cyrf. почитал документацию, поискал софт. все есть, все понятно. камни в продаже в принципе есть и кое-где даже в наличии. ядро и потроха одинаковые у семейства cy8c21х34 и отличаются только корпусами. cy8c21234 в корпусе SOIC-20 стоит 90р, cy8c21434 в QFP стоит 200 рублей. примерно.
покупать оригинальный программатор за 30$ который у нас барыжат за почти 100 некомильфо. курил доку на протокол программирования, начал писать программу для мега8. не буду использовать аппаратный SPI меги, решил подрыгать ногами. прошивку для кипреса буду заливать Z или Х модемом в бинарном виде из терминала.
в планах:

  1. сделать программатор для камней серии cy8c21х34 с включением режима программирования по ресету и по питанию. плату с мегой запихать внутрь коробочки с чипом от пролифика. заодно решается проблема постоянной нехватки СОМ портов в компе и питания программатора/таржета.
  2. сграбить и отреверсить обмен между трансивером и процом в режиме приема пакетов и привязки.
  3. сграбить и отреверсить протокол модуля ТМ1100, т.к. толку сниффить обмен между ВЧ блоком телеметрийного модуля и процессора на плате сбора данных с аналоговых датчиков дело заведомо провальное. ведь приемник/сателлит не очень-то желает работать на передачу.
  4. прицепить “оранжевый” приемник в качестве телеметрийного модуля к ДХ8.
Tags:
This site will not work without javascript!
This site will not work if cookies are completely disabled.
Site is offline
  • 34.15ms - Total
    • 0.06ms - http_prepare
    • 0.02ms - cookies_read
    • 0.01ms - tz_offset_read
    • 27.84ms - server_chain_exec
      • 0.04ms - session_load
      • 0.01ms - session_new
      • 0.04ms - csrf_token_set
      • 0.04ms - fill_session_from_AuthSession
      • 0.08ms - fetch_guest_user_info
      • 0.07ms - fill_user_info_locale
      • 0.01ms - layout_common_set
      • 0.20ms - show_announces
      • 24.33ms - server_method_exec
        • 0.14ms - offline_mode_check
        • 1.63ms - fetch_user_by_hid
          • 0.20ms - fetch_can_see_deleted_users
          • 1.38ms - fetch_user_by_hid
        • 0.21ms - bot_member_pages_forbid_access
        • 0.11ms - fetch_current_tag
        • 9.93ms - subcall_entry_list
          • 0.36ms - fetch_and_fill_permissions
          • 0.04ms - define_visible_statuses
          • 1.68ms - get_entry_ids
          • 4.03ms - fetch_and_sort_entries
          • 1.25ms - fetch_and_fill_bookmarks
          • 0.30ms - fetch_infractions
          • 0.05ms - collect_users
          • 1.23ms - check_ignores
          • 0.59ms - blog_entries_sanitize_and_fill
        • 5.06ms - fetch_tags
        • 1.17ms - fetch_categories
        • 2.05ms - fill_pagination
        • 0.06ms - fill_head
        • 0.05ms - fill_breadcrumbs
        • 3.73ms - fill_prev_next
      • 0.01ms - fill_runtime_locale
      • 0.20ms - inject_acp_access_state
      • 0.05ms - fill_runtime_user_info
      • 0.19ms - inject_dialog_permissions
      • 0.01ms - token_live_inject
      • 0.18ms - fetch_can_see_deleted_users
      • 1.44ms - users_join
      • 0.01ms - add_users_to_page_data
      • 0.01ms - session_ttl_increase
      • 0.10ms - assets_info_inject
      • 0.01ms - footer_common_inject
      • 0.01ms - navbar_common_inject
      • 0.01ms - recaptcha_pubkey_inject
      • 0.14ms - session_save
      • 0.01ms - session_delete
      • 0.01ms - last_active_update
      • 0.11ms - token_live_save
      • 0.23ms - response_to_plain_object
    • 0.01ms - not_modified_check
    • 0.02ms - http_loading_stub
    • 5.91ms - http_render
    • 0.03ms - inject_security_headers
    • 0.00ms - puncher_end