Что изменилось за последние 10 лет?
ну как вариант, что бы не “плодить количество” каналов, так как это плохо сказывается на качестве связи.
хотя, тем которые FPV юзают это не имеет значения )
что бы не “плодить количество” каналов, так как это плохо сказывается на качестве связи.
Фреймы с измерениями передаются постоянно, вне зависимости от значения. Их размер также неизменен. То есть это постоянный поток сообщений с некоторой частотой.
Для CRSF например пакет управления.
struct crsfPayloadRcChannelsPacked_s {
// 176 bits of data (11 bits per channel * 16 channels) = 22 bytes.
unsigned int chan0 : 11;
unsigned int chan1 : 11;
unsigned int chan2 : 11;
unsigned int chan3 : 11;
unsigned int chan4 : 11;
unsigned int chan5 : 11;
unsigned int chan6 : 11;
unsigned int chan7 : 11;
unsigned int chan8 : 11;
unsigned int chan9 : 11;
unsigned int chan10 : 11;
unsigned int chan11 : 11;
unsigned int chan12 : 11;
unsigned int chan13 : 11;
unsigned int chan14 : 11;
unsigned int chan15 : 11;
} __attribute__ ((__packed__));
В SBUS практически тот же принцип
The SBUS protocol uses an inverted serial logic with a baud rate of 100000, 8 data bits, even parity, and 2 stop bits. The SBUS packet is 25 bytes long consisting of:
Byte[0]: SBUS header, 0x0F
Byte[1 -22]: 16 servo channels, 11 bits each
Byte[23]
Bit 0: channel 17 (0x01)
Bit 1: channel 18 (0x02)
Bit 2: frame lost (0x04)
Bit 3: failsafe activated (0x08)
Byte[24]: SBUS footer
только передается 24 байта, 16 полноценных каналов и 2 дискретных. но это практически предел.
В SBus2 между приемом пакетов данных идет отправка пакетов телеметрии.
Но я не совсем об этом,
по большому счету никому не надо 16 11 битных каналов.
- запихать в пакет можно любое количество каналов, это совсем не трудно,
вот только если каналов больше 10 сделать период обновления 7 мс будет совсем не просто.
При частоте отправки фреймов 50 в секунду обновление управляющих значений будет с интервалом 20ms. Возможно, есть фантастические люди с нейро-мышечной реакцией глаза-голова-руки в 20ms, но например у самых тренированных спортсменов она где-то 120-150ms, насколько мне известно. То есть за время типовой реакции придет 8-12 фреймов с измерениями.
Олег, я бы порекомендовал пообщаться по этому вопросу с вертолетчиками.
Про себя скажу, начинал с вертолетов и Турнига 9Х, потом пересел на самолеты,
а когда пересел на Футаба 8FG реально “почувствовал разницу”.
я понимаю, что 2048 отсчетов мало кто на ручке почувствовать сможет,
но на уровне подсознания, разница между 2048 и 1024 все таки есть ).
На турниджи, вроде 512 импульсов. FG не знаю на 7 сап 1024 по мануал у.
могу ошибаться, но вроде в альтернативе ±512 было, хотя … тем более 512 супротив 2048
В SBUS практически тот же принцип
SBUS это общий интерфейсный протокол, внутри трансивера между управляющим контроллером и радиомодемом может формироваться совершенно другая упаковка. То же справедливо и для CRSF, но кажется в TBS передаеться as is.
16 полноценных каналов и 2 дискретных. но это практически предел.
Да ну нафик =) Для Lorawan радиомодема, если не изменяет память, максимальный payload для фрейма чуть ли не 4kb. Впихнуть 24 канала не проблема. И ничего не мешает строить сложные схемы передачи, что собственно и делают в приложениях… cdn-shop.adafruit.com/…/sx1276_77_78_79.pdf
Но да, согласен, возможно для любителей это не шибко необходимо. На крыле с 6-7 режимами полета укладываюсь в 8-9 каналов, включая газ-элевоны, ну еще пищалка.
но на уровне подсознания, разница между 2048 и 1024 все таки есть
Это субъективные ощущения. Никто не проводил испытания в слепом тесте на группе. При желании можно как в случае с теплым ламповым звуком, спорить до взаимной перестрелки =)
PS Чего-то сразу не вспомнил. Реально для управления используется диапазон 1000-2000. То есть реальная дискретность в канале управления 2^10.
Поэтому турнигу быстро слил, попытался на металку закрылки программировать и понял, что у нее разрешение никакое. Хотя ля простых моделек с дешёвыми сервами пойдет.