Как принять сигнал с приемника в AVR (PWM|Digital)
Если вдруг удастся разыскать такой приёмник, то работать будет хреново. Успокаивает то, что производство таких приёмников на сегодняшний день крайне нецелесообразно.
чуш!!! все приёмники 2.4гг от футабы так и работают!!!
все канальные импульсы начинаются в один момент!!!
я вот просто тоже работал в аналогичной теме…над sbus шиной… поэтому и посмотрел осцилом как там что идёт!
и у меня тоже возникла одна проблема которую я не решил!!!
а проблема такая!!! вот есть у нас 16каналов по 11бит и 2 канала по 8 бит… тоесть в числовом виде!!!
как из этого сделать 18 каналов пвм импульсов??? получается что нужен процик ч тактовой в мгц 100-150… либо специализированая МС…
вот на логике это я могу сделать… но будет куча корпусов 😦
а програмно смысл такой…что просто бежит счётчик…и на один его такт… сравнивается с канальным значением… тоесть это надо сделать 18 раз…
а так как проц 8 бит. а оперируем в 16… то код увеличивается ещё вдвое!!! кароче просто не успеваем…
на меге8 с 16мгц можно успеть 1-2 канала всего 😦
а вот если канальные импульсы сдвигать один за одним… то проблеммы появятся уже с их периодом!!! 😦
чуш!!! все приёмники 2.4гг от футабы так и работают!!! все канальные импульсы начинаются в один момент!!!
По логике такой вариант сам просится, алгоритм достаточно простой и быстрый выходит. сброс таймера в ноль и на все выходы подать активное напряжение, одновременно записью в регистр по 8 бит, после этого в цифровой компаратор таймера поместить длину самого короткого импульса, по срабатыванию снять активный бит и вписать следующее значение… и так пока не отработают все каналы… потом додерживается синхро пауза и все сначала…
а так как проц 8 бит. а оперируем в 16… то код увеличивается ещё вдвое!!!
так длинные каналы вроде как передаются в серии не целиком, а через раз “по половине”, а 8-ми битные влезают целиком в каждую серию…
алгоритм достаточно простой и быстрый выходит.
Да, я сделал именно так. Сортировка по времени массива структуры (маска сброса (канал), время канала), установка уровня по всем каналам, сброс таймера и вперед… в глухом цикле сравнение с очередным каналом и его сброс. Только прерывания должны быть на это время запрещены, что требует синхронизации с остальными процессами (получение значений итп.).
в случае с таймером чтобы результат был один и тот же нужно таки своевременно отследить переполнение счетчика.
Нет, не нужно. Пусть 8-битный таймер меряет импульс шириной 20 тиков. Без переполнения 30-10=20, с переполнением 10-246=-236 Оба результата в 8-битном двоичном формате будут выглядеть как 10100
кто то имеет реальную временную диаграмму
Уже был пост #110 стараниями AndyBig. Вы хотите ещё таких-же картинок? Других мне пока получить не удалось.
чуш!!! все приёмники 2.4гг от футабы так и работают!!! все канальные импульсы начинаются в один момент!!!
Большое спасибо за информацию! FASST никогда в руках не держал, надо срочно проверить эту не очень приятную новость!
Да, я сделал именно так.
Сергей, как боретесь с джиттером? Ведь чем больше каналов, и чем “одинаковее” их длительности, тем больше вероятность конфликта по времени спада импульсов?
Большое спасибо за информацию! FASST никогда в руках не держал, надо срочно проверить эту не очень приятную новость!
а что её проверять то??? вот например приёмник 6014…
тоесть 14 каналов… период импульсов 14мс… вот… а если все 14к выстроить один за одним по фазе… и при максимальной длительности импульса получим
14Х2=28мс… тоесть время в два раза больше времени периода 😦
Сергей, как боретесь с джиттером? Ведь чем больше каналов, и чем “одинаковее” их длительности, тем больше вероятность конфликта по времени спада импульсов?
согласен! когда время не равно а очень близко и по цыклам …лажа может получится… не вариант…
так длинные каналы вроде как передаются в серии не целиком, а через раз “по половине”, а 8-ми битные влезают целиком в каждую серию…
я говорю не про передаются а про обработку!!
да и передаются не по половине а… 8+3_5+6_2+8+1 итд…
да и передаются не по половине а… 8+3_5+6_2+8+1 итд…
я имел ввиду половина каналов сейчас, вторая потом )) чередуются, четные /нечетные.
я имел ввиду половина каналов сейчас, вторая потом )) чередуются, четные /нечетные.
это где так каналы передаются???
пс
выше я описывал передачу по сбусу
Уже был пост #110 стараниями AndyBig. Вы хотите ещё таких-же картинок?
Спасибо, глянул, странно что я тот пост раньше пропустил, вроде стараюсь следить за темой.
Пришла в голову мысль. (поздравлять не надо, поздно уже)
А какая нам собственно разница, одновременно ли выходят канальные импульсы или поочередно? ведь если их выгонять одновременно, тогда приемнику надо каждый из них обработать, вычислить длину, сохранить, потом ее отработать на соответствующем канальном выходе, для этого придется задействовать таймер, но ведь во всем этом нет ни какого смысла, если только приемник не ужасно умный и сам знает что хочет. Но это уже, считай что это уже целый робот/автопилот с ручной корректировкой… Что то мне подсказывает что ни один приемник вообще не вычисляет эти длительности импульсов из приходящей серии. А тупо “сортирует” их по номеру и выставляют в канал один в один, точно так же как это бы сделал и сдвиговый регистр. В таком случае и погрешность в длину практически не будет внесена. Просто у импульса появятся красивые фронт и спад а сам импульс сдвинется по времени на несколько тактов CPU - на время реакции процессора, а она достаточно быстрая и главное одинакова в обоих случаях и при установке и при сбросе канала… зачем приемнику что то улучшать в сигнале или разбираться в нем?
тогда перефразирую свой вопрос
Кто же видел правду?
Один из совершенно достоверных вариантов нам известен, но единственное ли это применение?
Кто нибудь видел приемники работающие иначе? Очевидно Нужно посмотреть, проверить, как себя ведут приемники от разных производителей… хотя бы самых распространеных.
вот… это …жолтая линия - 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 делать не будем 😃.