FrSky 2.4GHz FHSS, новый игрок на рынке 2.4ГГц
Диод с резистором это минимум , для любителей экономить , транзистор лучше (он вам и проинвертирует), а еще лучше преобразователь уровня , но но в данном случае преобразователь уровня IMHO слегка излишество , но если бы делал не для себя а для промышленного применения то преобразователь уровня поставил бы обязательно. Транзистор IMHO самый оптимальный вариант , пример есть в описании протокола www.frsky-rc.com/…/20100921121837352.pdf только в вашем случае VCC = 5V
идет -5 +5В, а хотелось бы 0…5В.
Сделайте, как здесь rcopen.com/files/4cf5717199707300771870f3
Это из темы rcopen.com/forum/f8/topic210730
По-моему, это самое простое. Сдвиг на диоде. Инвертирую программно.
Самое простое для выполнения требований DS , но отсутствует какая либо защита.
Желателно добавить резистор между TX и диодом (ом 300 -500) и резистор между RX и GND (1-10К)
Сделайте, как здесь forum.rcdesign.ru/…/attachment....6&d=1291153777
Почти правильная схема , не хватает резистора с базы T2 на массу
Первая схема будет работать с фрискаем но если воткнуть в полноценный сом порт ±12 сгорит а при ±3 работать не будет , вторая свободна от этих недостатков
Между входом RX и GND должен быть резистор в несколько КОм… На высокоомном входе можно получить неустойчивый “0”…
не хватает резистора с базы T2 на массу
Я тоже предпочитаю ставить резисторы с базы на корпус, особенно в тех случаях, когда устройство может эксплуатироваться с не подключенным входом…
Автор схемы, наверное, не планировал использовать свой модуль без подключения к источнику данных… Поэтому посчитал резистор ненужным 😉…
Автор схемы, наверное, не планировал использовать свой модуль без подключения к источнику данных…
В жизни к сожалению не все идет по плану , проводочек отвалится например.😉
К посту 1720 для Pav_13. То что вам не понятно в протоколе это обычный байтстаффинг, это очень не сложно: Если в текущих данных (принимаемый кадр) встречается байт 0x7E, то он подменяется двумя байтами 0x7D и 0x5E, если в принимаемом кадре встречается байт 0x7D, то он подменяется на два байта 0x7D и 0x5D. Соответственно, при “разгребании” приемного буфера количество байт в нем от 0x7E до 0x7E (от стартового до стопового байта) будет разным, потому что в передаваемых данных будут проскакивать байты 0x7E и 0x7D. Учитывая вышеописанную особенность, в программке нужно делать все в обратном порядке…
обычный байтстаффинг
Вот спасибо! и главное пока не сказали я этого в описании протокола в упор не видел , и думал же как быть если в данных 7E 😃
он подменяется двумя байтами
Можно заранее заменять запрещенные значения 0x7E и 0x7D на ближайшее меньшее или большее, чтобы не было байтстаффинга. Если с датчика пришло 0x7E=126, то заменить на 0x7F=127 и отдать в приемник (аналогично, запрещенный “7D=125” заменить на 7С=124). Тогда чип внутри приемника\передатчика не будет делать подмены байтов, длина принятого слова будет постоянной. А погрешность датчика 126~127, 125~124 не критична.
А погрешность датчика 126~127, 125~124 не критична
Для напряжения или оборотов может и не критично , а я хотел туда GPS пустить, чтоб если что, искать легче было. Видимо на выходные достану это дело из долгого ящика.
Наверное можно и так делать, дело каждого, но это не правильное решение, гораздо проще делать все как говорится “по человечески” 😃, и это абсолютно не сложно и очень быстро на самом деле.
Совершенно верно! Для датчиков, контролирующих постоянно меняющуюся величину с точностью в 8 разрядов - некритично… А вот, если точность нужна выше (одного байта мало) или данные представляют собой достаточно сложную структуру (тот же GPS) - такой способ не годится…
С удовольствием посмотрел бы на правильный алгоритм разбора таких пакетов данных… Можно на С, можно ромбиками-квадратиками… Если у кого есть ссылка - дайте…
Игорю Лытневу: Правильно, доставайте, если будут вопросы или непонятки подскажу-помогу по возможности… У меня тоже мысль есть, освободить аппаратный уарт у меги для гпс приемника а в фриску “пихать” какой-нить любой ножкой, но это как время позволит.
Павлу Бакулину: Если нужно могу показать как в моей прогрммке это написано на “СИ”, но только позже, вечером скорее всего, сейчас нет моих исходников под рукой.
Да! Посмотрю с удовольствием… Может, даже пойму чего-нибудь 😃…
У меня была мысль, подключить GPS-модуль прямо к приемнику… Для летающей модели этого было бы вполне достаточно - скорость, высота, направление на базу, координаты… Летал с телеметрией от Smalltim только с GPS-модулем - вполне устраивало!
Запустил Ская через 2Ватный бустер,значения остались прежними.
Для Павла Бакулина: Нашел на флешке свои исходники, вот кусок в котором обрабатывается приемный буфер. RX_ptr - это это переменная которая после принятия стопфлага 0x7E из уарт принимает соотв. значение…
if(RX_ptr&0x80) //Если приняли буфер по UART, то разгребаем его…
{INT8U data, m=0;
for(i=0; i<8; i++) //n<=RX_ctr;
{if(RX_buf[i]==0x7D) data=RX_buf[++i]|0x20; //байтстаффинг
else data=RX_buf[i]; //байтстаффинг
switch (RX_ptr)
{case 0x81: {data_Ur[m]=data; break;} // Пользовательские данные (грузим в буфер)
case 0x82: {DATA_Fr[m]=data; break;} // Данные FrSky (грузим в буфер)
default: break;
}
m++;
}
}
Если у кого есть ссылка - дайте…
В описании протокола есть: When byte 0x7D is received, discard this byte, and the next byte is XORed with 0x20;
Упс , опоздал.
Илья, спасибо! В приведенном Вами фрагменте кода знакомые буквы вижу - попробую “вкурить” 😛…
Игорь, я пытался перевести Гуглом эту строчку из описания протокола - результат неутешительный 😦…
Вы можете растолковать эту строчку по-русски?
Игорь, я пытался перевести Гуглом эту строчку из описания протокола - результат неутешительный …
Вы можете растолковать эту строчку по-русски?
При приеме 0x7d , отказаться от этого байта, а следующий байт XORим с 0x20;
что собственно у kuznetsovin и сделано :
if(RX_buf[i]==0x7D) data=RX_buf[++i]|0x20;
в результате
вместо : 0x7D 0x5E имеем 0x5E XOR 0x20 = 0x7E
вместо : 0x7D 0x5D имеем 0x5D XOR 0x20 = 0x7D
Павел: если детально, то… если время приема встретится байт 0x7D (When byte 0x7D is received), выбросите его (discard this byte), ваш следующий байт будет в результате логической операции - and the next byte is XORed with 0x20… В моей программке это написано:
if(RX_buf[i]==0x7D) data=RX_buf[++i]|0x20; //байтстаффинг
else data=RX_buf[i]; //байтстаффинг
опоздал 😃
XOR им с 0x20
Ну, вот! Стоило всего-лишь добавить “русское” окончание к абревиатуре XOR - сразу дошло! Спасибо!
Ну, вот! Стоило всего-лишь добавить “русское” окончание к абревиатуре XOR - сразу дошло! Спасибо!
Я вообще этот кусок в описании не замечал пока не услышал от kuznetsovin слово “байтстаффинг” , за что ему еще раз огромное спасибо , теперь дело пойдет.
Игорь и еще, как бы не маловажное на мой взгляд, может еще кому-то интересно, после того как “разгребешь” байтстаффинг и определишь по байту 0xFD-(что данные юзерские), смотри следующий байт-(количетво верных байт в кадре) и если он равен шести, то тогда их-(юзерские данные) используй, я делаю именно так, потому что количество верных байт может быть меньше или они сдвинуты как-то, без этого условия в данных на приеме проскакивает “лажа”… Удачи! 😃
С этим я как раз разобрался , я именно про байтстаффинг прощелкал , поэтому иногда получал лажу , и кинул все в долгий ящик, думал фриска глючит , а оказалось как всегда : человеческий фактор .
А от чего у вас такой симпатичный дисплейчик ?
Дисплейчик от моторолы Т190, С200 графический, интерфйс I2C, встроенный драйвер в нем PCF8548. Джойстик для навигации по меню, тоже от мобилы + кнопочка… В плане удобства отображения на нем вроде как гораздо удобней чем на символьном, да и интерфейс последовательный, что не маловажно. Вот вид поближе немного.