Как принять сигнал с приемника в AVR (PWM|Digital)
вот… это …жолтая линия - 1й канал поданый в синхровнизацию
а зелёная это 2й канал…345678 выглядят также!!!
это приёмник Futaba R6208SB !
также работают 4 6 7 8 и 14 каналов приёмники от футабы! 😃
когда время не равно а очень близко и по цыклам …лажа может получится… не вариант…
Проц atmega88, тактовая 15мгц (от rfm22b), прога тупо на си (наверняка можно оптимизировать на асме). Измерял для 4-х каналов с одинаковым временем. Разница по длине импульса между 1-м и 4-м каналом <20мкс. Причем ошибка статическая, никакого життера нет.
//-----------------------------------------------------
#define PPM_MIN_CH 1500 // 0.8ms*1875
#define PPM_MAX_CH 4125 // 2.2ms*1875
void OutPWM(void)
{
u_long l;
u_char i, ff;
union { u_int i; u_char ch[2]; } cnt;
typedef struct { u_char mask; u_int val; } tagDataPWM;
tagDataPWM DataPWM[6];
u_char NumChPWM;
tagDataPWM dp;
const u_char mask[]={ 0xdf, 0xef, 0xf7, 0xfb, 0xfd, 0xfe };
for(i=0; i<6; i++)
{ // scale
DataPWM[i].mask=mask[i];
l=gMainData.ChVal[i]; l*=(PPM_MAX_CH-PPM_MIN_CH); DataPWM[i].val=(u_int)(l/256);
DataPWM[i].val+=PPM_MIN_CH;
}
ff=1;
while(ff)
{ // sorting
ff=0;
for(i=0; i<(6-1); i++)
if(DataPWM[i].val>DataPWM[i+1].val)
{ dp=DataPWM[i]; DataPWM[i]=DataPWM[i+1]; DataPWM[i+1]=dp; ff=1; }
}
NumChPWM=0;
#asm("cli")
PORTC=0x3f;
TCNT1H=0x00;
TCNT1L=0x00;
while(NumChPWM<6)
{ // work
[0]=TCNT1L; [1]=TCNT1H;
if(cnt.i>=DataPWM[NumChPWM].val)
{
PORTC&=DataPWM[NumChPWM].mask;
NumChPWM++;
}
}
#asm("sei")
}
//-----------------------------------------------------
Написал на скорую руку для оценки работоспособности, но понравилось как работает… и пока нет желания дальнейшей оптимизации…
я на си не понимаю… тока асм 😦
появилась мысль!!! как быстро вывести паралельно канальные импульсы.
вот время на обработку у нас гора!!! а вот время на вывод у нас строго ограничено!!!
вот пример на 8ми каналах!!!
11111111
11111111
10111111
10111111
10001111
10001111
00000011
00000000
00000000
по горизонтали № канала
по вертикали время!!!
и всё это в озу!!!
тоесть сперва подготавливаем типа маску… а потом выводим её
на 8 каналов в 2048 понадобится проц в 2к озу!!!
😃 а на 16 каналов вполне подойдёт ATmega644 4к озу!!!
4к маловато!!! по сбусу реально передаётся число больше чем 2048!!
добавлено ещё 256!!! это поле тримера!
- надо ещё гдето хранить сами данные считаные со сбуса!!! 36 байт!
итого = 4096+512+32 это минимум для 16 каналов
а каналы 17 и 18 так как они дискретные можно вывести со здвигом по фазе!!!.. и там всего дискретность 256
тоесть ещё +256
в 8к всё влазиет!!! итого процик ATmega1281
Кто же видел правду?
Стандартный РРМ не позволяет организовать больше 8 нормальных каналов. Вариант пачки с общим передним фронтом содержит риски по питанию, связанные с одновременным стартом нескольких серв (см. тему про барабашек). Поэтому представляется логичным существование или появление промежуточного варианта (хотя-бы в качестве маркетингового хода), когда передние фронты канальных импульсов будут формироваться со смещением, скажем в 100 мкс.
Вариант пачки с общим передним фронтом содержит риски по питанию, связанные с одновременным стартом нескольких серв (см. тему про барабашек).
ну да!!! вся кантора футаба ацтой!! сидят там и нихрена не делают ? 😃
И Спетрум - тоже 😃. Щас все фирмы “отлаживают” технику непосредственно на покупателях. Патамушта все конкуренты так делают. А покупатели хавают и думают, что так и должно быть. Футаба серии “Голд” ходила 20 лет без ремонта, а щас все интересуются “где купить потенциометры”. А вообще, когда к схеме добавился софт, жизнь стала гораздо интереснее. Но мир вокруг как-то быстро становится одноразовым.
V_Alex … лет 5 назад ябы с вами согласился!
Да мне согласие как-бы и не требуется. Я в теме больше 20 лет и хорошо знаю, что глюки могут вызываться не только отдельными факторами, но также их комбинациями, которые невозможно воспроизвести на стенде. А в реале они возникают сами собой, порождая легенды о барабашках и киллсвичах, мешающих работе отличных фирменных приемников. Поэтому три главные детали в любом приемнике - хороший лоудроп и пара электролитов. Без этого ни один приемник работать нормально не будет.
У меня щас есть конкретная задача - принять два канальных импульса с приемника с 16-битной разрядностью, обработать и выдать на выход в этом-же фрейме с разрядностью не хуже 10. Пока был единый РРМ стандарт, все было бело и пушисто, особенно, если при этом знаешь, какой приходит первым, а какой вторым. А вот если сценарий прохождения импульсов заранее неопределен, неизвестна последовательность и характер наложения импульсов друг на друга, все получается гораздо интереснее. Понимаю, что придется писать модуль распознавания сценариев, но душа жаждет халявы 😃
P.S. Теоретические рассуждения о том, что одного байта на канал на все про все - выше крыши, мне неинтересны.
У меня щас есть конкретная задача - принять два канальных импульса с приемника с 16-битной разрядностью, обработать и выдать на выход в этом-же фрейме с разрядностью не хуже 10.
О! блин все с ног на голову. Но какой смысл получать хороший сигнал для “замены” его плохим? если удается оцифровать 16 бит, значит и дальше можно их же и передать. либо оцифровывать сразу с некоторой погрешностью допустим сразу проигнорить 2-4 бита и обрабатывать заведомо с 12-14 битной точностью.
Единственное что приходит в голову в “оправдание” такой деятельности, это что тебе возможно хочется получить сигнализацию с пары лишних каналов, а потом их обработать совсем по своему закону? Сознавайся! И ставь задачу поточнее, возможно появятся и полезные идеи.
Сознавайся! И ставь задачу поточнее, возможно появятся и полезные идеи.
Универсальный, нормально работающий V-tail смеситель, соответствующий требованию: “сделал, отдал, забыл” 😃
…задача - принять два канальных импульса с приемника с 16-битной разрядностью, обработать и выдать на выход в этом-же фрейме с разрядностью не хуже 10.
Пока был единый РРМ стандарт, все было бело и пушисто,
Понимаю, что придется писать модуль распознавания сценариев, но душа жаждет халявы 😃
P.S. Теоретические рассуждения о том, что одного байта на канал на все про все - выше крыши, мне неинтересны.
вот и я про то 16бит это уже довольно высокая точность но её всеравно не получить…азза не моментального срабатывания прерывания…
проще получить эти данные с сбуса футабы!!! со 100% точностью 😃
нафик разные стандарты??? делать под конкретный приймник!!!
8бит меня тоже не устраивает
При аппаратном замере 16 бит получаются автоматически. Если мерять программно, хватит 12 бит. Серве нужно 10 бит. “PPM only” а-ля GWS делать не будем 😃.
Для 16-бит один квант будет ~15ns…😃
Серве нужно 10 бит.
Существуют сервы способные выдать точность <0.17град (даже для диапазона полного хода 180град)? И это реально необходимо для авиамодели?
проверил ещё раз!!!
диапазон изменения числа в канале в сбус шине футабы
0001 до 07FF
первые 6 каналов идут в паралель!!! и только на них распространяется режим хайспид!!!
а вот начиная с 7го!!! они отстают на 3мс от первых 6ти!!!
тример работает от 2047 до 1680 = 367
тоесть поле деятельности тримера 367
а поле деятельности стика 1680
нафик разные стандарты??? делать под конкретный приймник!!! 8бит меня тоже не устраивает
под конкретный приемник не интересно, тк не выполнится условие изготовления “сделал-отдал-забыл”, ибо забыть не получится на долго, так и будут приходить и клянчить переделку под другой приемник, потом под третий.
Крнстантин, поделись названием програмки-осциллера или это спец софтина от аппаратной приспособы?
…это спец софтина от аппаратной приспособы
это усб осцил… 1 канал… мож у автора есть уже что и покруче…
называется pv6501… пользую уже лет 5… про свой 1С-77 уже забыл 😃
под конкретный приемник не интересно, тк не выполнится условие изготовления “сделал-отдал-забыл”
универсальная вещь она всегда хуже!!! в таком случае можно сделать устройство под каждое устройство! либо в одном переключать вариант работы!! либо сделать автомат распознающий вариант работы
есть большой проект… ил-76 3600см… автор не я поэтому без подробностей…
в одном крыле 14 машинок… с использованием 7и каналов.
моя задача помочь человеку с бортовой сетью!! вот и пришла такая мысль…
поставить приёмник R6208SB … всё что в фюзе и не отстёгивается запитать от первых 8и каналов…
а всё что снимается… и чтобы не парится в проводах… решено подсоединится по сбусу!!!
тоесть надо грамотно организовать декодер сбус в канальные импульсы!!!
с самой шиной сбус я уже разобрался что там и где передаётся
осталось только из числа 0001 до 07FF сделать 7-8 канальных импульсов!!! 😃
… поле деятельности тримера 367
а поле деятельности стика 1680
Хоть с одним вопросом разобрались полностью, разрядности 10-11 бит серве достаточно 😃
под конкретный приемник не интересно, тк не выполнится условие изготовления “сделал-отдал-забыл”, ибо забыть не получится на долго, так и будут приходить и клянчить переделку под другой приемник, потом под третий.
Именно так. И не просто клянчить 😃
Именно так. И не просто клянчить
Вот вот. Готовь схемку летом, а прошивку зимой… )))
В том плане даже если сделаешь “полуфабрикат” то прежде чем успокоиться придется подготовить софтину версии 2 на все случаи жизни, или как минимум “подбить базу” чтоб быть готовым к модернизации устройства, ибо нет такого заказчика который бы сплющив человеку мозг, вот так легко успокоился бы на достигнутом )))
первые 6 каналов идут в паралель!!! и только на них распространяется режим хайспид!!!
а вот начиная с 7го!!! они отстают на 3мс от первых 6ти!!!
В принципе, это тоже весьма ценная инфа 😃
Во-первых “сказка стала былью” - это по поводу смещения каналов на современных приемниках. А во-вторых, моя задача по части универсальности стала практически невыполнимой, попытка “универсально” смешать ФАСТ-канал с обычным ни к чему хорошему не приведет.
В принципе, это тоже весьма ценная инфа 😃
Во-первых “сказка стала былью” - это по поводу смещения каналов на современных приемниках. А во-вторых, моя задача по части универсальности стала практически невыполнимой, попытка “универсально” смешать ФАСТ-канал с обычным ни к чему хорошему не приведет.
Почему не приведет? и чем твоя конструкцыя может оказаться хуже того что было? И почему задача становится ни универсальной не понятно, ведь ты собирался каждый канал отслеживать полностью а значит и обрабатывать должен в любое время независимо от порядка следования импульсов.