wavelet shrinkage: threshold level

Если дисперсия щума нам заранее известна, тогда уровень threshold'а вычисляется довольно просто (см. предыдущий пример). В противном случае существует методика оценки дисперсии из высокочастотной части первого уровня разложения:

#вычисляем коэффициенты разложения
coeffs = pywt.wavedec(data, 'coif3', 'cpd', dec_level);

#оценка шумовой дисперсии из высокочастотной части первого уровня разложения
#как median absolute deviation (MAD) деленное на 0.6745
MAD = abs(max(coeffs[dec_level]) - median(coeffs[dec_level]));
sigma = MAD/0.6745;

#вычисление уровень threshold'а из шумовой дисперсии
tr_level = sigma*sqrt(2*log(len(data)));
print tr_level;

wavelet shrinkage & python (pywt)

Делюсь примером, написанным на python с использованием pywt, который показывает как производится фильтрация сигнала от шумов при помощи техники wavelet shrinkage.

Теряются байты FT232RL USB-UART

Пишу программку для шабашки. Программа должна запускаться на плате AT91SAM9 и обеспечивать обмен с другим устройством по UART. Решил отладить программу на писишке. Для чего использую преобразователь на FT232RL. Вроде все тупо и просто, но на некоторые посылки устройства писишка не отвечает и устройство выдает ошибку по таймауту. Начал разбираться. Оказалось, что некоторые посылки частично или полность теряются где-то по пути после FT232RL. Либо программу я коряво написал, либо какой-то глюк преобразователя и драйверов - пока неясно. Завтра надо притащить кабель и преобразователи MAX чтобы соединить UART'ы старым дедовским способом. Прямое соединение невозможно по причине разных уровней сигналов в двух устройствах в результате чего одно не видит посылки другого.

Запуск Debian Lenny на AT91SAM9XE512-S3E

Пытался запустить Debian на платке. Пользовался мануалом http://lab.starterkit.ru/index.php?option=com_content&task=view&id=25&Itemid=9 Но к великому огорчению u-boot, который записан во флешку, не поддерживает загрузку с SD/MMC. Пришлось грузиться с tftp: ядро zlinux положил в папку /tftpboot у себя на ПК, в u-boot задал переменные:

• setenv serverip 192.168.0.1 - адрес tftp-сервера
• setenv bootargs rootwait=5 root=/dev/mmcblk0p2 console=ttyS0,115200 mem=64M - корневая фаловая хранится на втором разделе SD-карточки

Набрал в командной строке run tftp_boot, пошла загрузка ядра, затем подцепилась корневая файловая, платка получила адрес по dhcp. Залогинился по telnet - внутри debian linux со всеми потрохами, правда ядро староватое - 2.6.24, но я думаю здесь это некритично.

Работа с uart в linux

Руководствуясь "Serial Programming Howto", которое гуглится влет, написал небольшую программку, которая принимает данные по UART с ПК и пересылает их обратно, точнее накопипастил и исправил мелкие косяки. С ПК отправляю данные при помощи gtkterm. Прием асинхронный, при помощи сигналов.

AT91SAM9XE512-S3E

Выдали платку, чтобы написал программку и запустил на платке. http://www.evodbg.com/index.php?option=com_content&task=view&id=65&Itemid=83 На борту микроконтроллер ARM, 9й серии, всякая память и прочие устройства. В ARM запускается  и крутится Linux, что для меня сильно пока непривычно. Пытаюсь разобраться с этим добром. Пока что подключился через терминал к плате, могу наблюдать процесс загрузки, могу набирать команды в консоли. Воткнутая флешка автоматом определяется и подрубается в виде SCSI-диска, можно на нее писать и читать с нее. Автоматом поднимается сеть, можно соединяться по telnet, гонять файлы по tftp. Предоставляется готовый toolchain для сборки программ. Уже затестил "hello world!". Разбираюсь дальше.

26 Mar 2011

Решили на днях испытать протокол связи, реализованный для шабашки. Сразу вылезли всякие глюки, которые были в большинстве своем отловлены. Остался один самый неприятный глюк: время от времени МК отваливался по таймауту, причем в случайные моменты времени. В ходе отладки было обнаружено, что пропадает один байт. А все из-за чего? В программе МК крутится один главный цикл, в котором поллились флаги UART. Но так как данные приходят с относительно высокой скоростью, походу во время обработки пришедшего байта приходил следующий и таким образом терялся. Сделал работу UART'а по прерываниям - полученные байтики складываются в буффер. После этого гонял байтики в течение 4х часов. Не было ни единого разрыва!

Про netcat и ncat

Возникла задача отправлять и принимать данные от отлаживаемого устройства. Да не по абы какому интерфейсу, а по неведомому и недосягаемому ethernet. Для этого использовал утилиту netcat. Однако данная утилита не умеет отправлять и принимать данные в шестнадцатеричном виде, что очень меня огорчало и побуждало в процессе отладки всячески поносить разработчика. Приходилось извращаться всяко-разно. Однако наткнулся на другую очень полезную штуку - ncat. Почти то же самое что и netcat, но умеет делать дамп принимаемых данных в нужном формате при помощи ключика -x. Итого:

1) echo -ne "\x01\x02\x03\x04" | ncat -i 1000 -x output.hex address port

2) cat output.hex

Как можно догадаться \x01\x02\x03\x04 - это байты, которые отправляются в устройство, где \xHH - число в шестнадцатеричном представлении.

Protothreads

Обнаружил довольно забавную вещь - протопотоки. На них можно реализовать нечто вроде кооперативной ОС (на самом деле это просто удобная макрообертка машины состояний) для маленьких девайсов, у которых не так уж и много ресурсов для реализации хотя бы полноценной кооперативной ОС с сохранением контекста и прочего. Почитать можно здесь http://bsvi.ru/protopotoki-protothreads/ и первоисточник http://www.sics.se/~adam/pt/. Пока разбираюсь.

Real Time Kernel

В свете продвижений по шабашке с 8051 решил посмотреть какие real time kernel's существуют для данной архитектуры? В итоге обнаружил:

1.  RTX51 Tiny небезызвестной конторы keil. Однако у меня компилятор "другой конторы". Хотя вроде как написана на ассемблере. Исходников не видел.
2. uC/OS-II порт, сделанный кем-то и как-то. На офф. сайте не нашел
3. freeRTOS. Говорят тяжелая и избыточная для наших задач.
4. Предлагают опробовать MacrOS: Simply RTOS on Macroses http://galilley.blogspot.com/2010/07/macros-simply-rtos-on-macroses.html. Пока не разбирался.
5. Написать что-то свое - велики затраты времени

Пока разбираюсь. Накачал Танненбаума. Нашел интересную статью Build s Super Simple Tasker

27 Feb 2011

Начал отлаживать девайсину. Нашел пару огрехов в схеме:

• Питание 5В получается из более выского при помощи 7805, при этом более высокое нигде не используется. Правда пока неясно для чего это задумано, может быть так и надо. Пробросил провод мимо стабилизатора.
• Конфликтовали питания +3.3В и питание с разъема отладчика. Перерезал дорожку. 
• Не заводится кварцевый генератор, может быть и заводится, но нестабильно. Завтра потыкаюсь осциллом и прочими приборами.

Дебагер бодро дебажит из под виртуальной машины. Для отладки интерфейса приглядел и установил Wireshark. Правда пришлось немного подшаманить, чтобы Wireshark работал из-под не root'а.

CORDIC для SciLab, заодно тестируем вставку кода

Пока без подсветки, но все же.

//заполняем таблицу
i=1:10;
log10_table_p = log10(1 + 2^(-i));
log10_table_m = log10(1 - 2^(-i));

//выводим значение логарифма
x = 2;
printf("%f\n", log10(x));

//CORDIC
z = 0;
for i = 1:10
  if (x > 1)
    x = x - x*2^(-i);
    z = z - log10_table_m(i);
  else
    x = x + x*2^(-i);
    z = z - log10_table_p(i);
  end;
end;

printf("%f", z);

CORDIC

Имею задачу как можно быстрее вычислить десятичный логарифм с заданной точностью на микроконтроллерной платформе. Есть куча методов: табличный, таблично-интерполяционный, метод Бриггса (этот дядя в 1620г посчитал логарифм до 16 знака!!!). Обнаружил такой замечательный алгоритм, как CORDIC, для вычисления иррациональных функций типа логарифмов, арктангенсов и прочих синусов да косинусов, делений и умножений. http://www.ee.siue.edu/~gengel/pdf/cordic.pdf. Вкратце суть вычисления логарифма при помощи CORDIC: