Ruslan1

Да конечно пожалуйста. Сконвертировал из *.daq и добавил в архив и текстовый файл, расширение "csv". in_data32000SPS_4096pnt.zip И опять засада: у меня 822.5698 Hz :( четверти от выборки (по 1024 точек): 1: 822.5570 2: 822.5868 3: 822.5385 4: 822.5531 половинки от выборки (по 2048 точек): 1: 822.5842 2: 822.5649 Полная выборка (4096 точек): 822.5698 Получается, что измеряемая частота сильно плывет? такое теоретически возможно. Но как-то не вяжется с тем что я вижу глазами: я последовательно применяю два метода (подсчет периодов методом пересечение нуля и FFT-based: первый-второй-первый-второй...), и вычисленная каждым из них величина колеблется около своего значения частоты, причем FFT-baised больше. И разность того же порядка как разница между Вашей и моей цифрами. :(

Огромное спасибо! Вы меня обнадежили! Значит, я где-то напортачил с методом, если из тех же данных получаю не то. Как я говорил, альтернативный метод подсчета (измерение длительности периода с усреднением)дает меньшую величину, чем у меня. Полученная Вами цифра мне очень нравится :), пожалуйста, помогите мне ее достигнуть! Насчет несинусоидальности. Для меня струнные датчики новая область, но везде пишут что это именно синус на выходе. И датчик у меня честный промышленный, не самоделка. значит, что-то с условиями я не соблюдаю у себя на столе. Ну или как вариант- моделируется это колебание чем-то(дом шатается, я уже такое проходил с сейсмосенсорами, 7-й этаж уже болтается вполне предсказуемо), а датчик чувствительный. Это же относительно изменения частоты- может это так и должно быть, реально меняется показание. Искажение в усилительных каскадах прибора- может быть, конечно, но вот синус с генератора нормально через них проходит.... Но в данный момент очень хочется попробовать доползти до Вашей цифры. Как я уже писал, для меня ЦОС это новая область. Я уже не говорю о том, что Матлаб впервые установил дней десять назад. До всего дохожу в рабочем порядке, читая форумы и интернет-ресурсы. В результате родился этот файл testing_on_real_data2.txt (нужно переименовать в *.m). ниже привожу его же. он и возвращает указанное значение: Frequency_Response = 820.9413 FFT_N_SAMPLES = 4096; Fs =31250; alpha = 3.9 %% input data % read data from file filename = 'ADC.CSV'; fid=fopen(filename','rt'); data_in = fscanf(fid, '%d,'); fclose(fid); %% windowing for i=1:FFT_N_SAMPLES %Gaussian: tmp_n = abs(i - (FFT_N_SAMPLES)/2); tmp = alpha * tmp_n / (FFT_N_SAMPLES/2); coeff = exp(-0.5 * tmp*tmp); data_win(i) = data_in(i) * coeff; end %% fft data_fft = fft (data_win,FFT_N_SAMPLES); %% magnitude for i=1:FFT_N_SAMPLES/2 data_fft_abs(i) = 2.0 * abs(data_fft(i)); end %% maximum searching max = data_fft_abs(1); n_bin_max = 1; for i=1:FFT_N_SAMPLES/2 if (max < data_fft_abs(i)) max = data_fft_abs(i); n_bin_max = i; end end %% Gaussian interpolation m1 = data_fft_abs(n_bin_max-1); m2 = data_fft_abs(n_bin_max); m3 = data_fft_abs(n_bin_max+1); top_part = log (m3/m1); bot_part = 2*log(m2*m2/(m3*m1)); d = top_part/bot_part; % f = ( i + d ) * ( sr / n ) n_bin_response = n_bin_max + d; Frequency_Response = (n_bin_response-1) * Fs / (FFT_N_SAMPLES) Самым слабым местом мне кажется оконная функция, хотя может еще где напортачил. Сейчас нашел файлик, который я оцифровывал через саундкарту с этого же датчика в тех же условиях, но с другим аналоговым трактом и другим АЦП. Все-таки больше похоже на синус. in_data32000SPS_4096pnt.zip Файл читается в Матлаб после распаковки командой Значит я не только в математике напортачил..... Это я конечно завтра начну рыть.... Но вопрос остается открытым- как из того недосинуса получить частоту меньше чем у меня на полной выборке, неправильно выбран метод или более конкретные ошибки при реализации.....

Так это не датчик, а деталька, которую еще нужно в датчик превратить. А при желаемой Вам точности 0.1 градуса это еще стараться надо. Ну и там сноска в даташите есть: То есть он от любого пука при монтаже может начать измерять с меньшей точностью и это предусмотрено производителем :) А прикольно: точность гарантируется до того момента как его установили. то есть любое подключение уже не гарантирует точность. Нужно запомнить, очень хороший финт ушами, если в документации написать. Надеюсь, фраза еще не запатентована :)

Ага, согласен. и у меня то же самое, даже график приводить не буду- один в один. конечно не синусоида, под "синусоидальностью" я подразумевал форму, издалека похожую на синус :) Ну и период равен бину, а не пол-бина, как в моем сообщении, это я куда-то не туда посмотрел. Но вопрос остается: можно ли изменением обработки приведенного массива изменить величину вычисляемой частоты? Если кто-то посчитает по своей методе и скажет мне результат, буду очень сильно благодарен! Вот привожу файлик исходных семплов АЦП (странно, файл с расширением csv загружать запрещено, пришлось в txt переобозвать). ADC.TXT Файл имеет простой текстовый csv-формат, который хоть в ексель хоть в матлаб подсовывается с пол-пинка. на всякий случай привожу код, как его в матлаб прочитать: Fs = 31250 FFT_N_SAMPLES = 4096 %% input data % read data from file filename = 'ADC.TXT'; fid=fopen(filename','rt'); data_in = fscanf(fid, '%d,'); fclose(fid); Мои результаты вычислений: 1. максимальный бин (индексы начинаются с единицы, как принято в Матлабе): n_bin_max = 109 2. расстояние от максимального бина: d = -0.3976 3. собственно координаты в бинах : bin = n_bin_max + d = 108.6024 4. Частота при указанных выше 31250 SPS и 4096 точках: freq2 = (bin-1) * Fs / (FFT_N_SAMPLES) = 820.9413 Согласно матлабу, результат может изменится на величину до -0.02 Гц при изменении коэффициента альфа в Гауссовском окне (от 4 до 10). Но в любом случае не достигается величина, показываемая методом подсчета пересечений через ноль (разница до -0.09 Гц от FFT-based метода) Кстати, у меня так и получается, что "результат всегда находится ближе к центральному бину чем реальное значение". Насчет "всегда" не знаю, но вот та же петрушка.....

Ну если так подходить, то почти любой mp3-плеер с функцией диктофона можно еще раз в 5-10 дешевле нетбука найти :). Если принципиально на съемную карточку- то наверное какую-то из мобилок можно посмотреть или опять же mp3-плеер но уже более редкая модель.

Отмечаю сразу всем, извините что не сразу. 0. Матлаб рулит! в который раз была доказана простая истина, что все нужно проверять на 100%, а потом уже в железо пихать :) 1. Обнаружена методическая погрешность из-за использования оконной функции. Погрешность имеет синусоидальный характер с периодом пол-бина и достигает например 0.06 Гц под Хэммингом. Вылечил использованием Гауссовского окна с альфой больше чем 3.9 - погрешность имеет тот же вид, но максимальное значение меньше чем 0.001 Гц (я стараюсь достичь такой точности). 2. На чистой рассчитанной синусоиде и синусоиде от генератора никаких дополнительных ошибок из-за использования целочисленного БПФ выявлено не было. Но при исследовании настоящих сигналов от датчика обнаружена разница в вычислениях в даблах Матлаба и целочисленного БПФ. Перешел на 32-битный float (беру FFT4096), разница с Матлабом стала исчезающе мала. Думаю, что реальный сигнал имеет отклонения от идеальной синусоиды, и эти искажения по-разному влияли на результат при использовании вычислений разной точности (float против short) 3. Насчет преобразовать в комплексный сигнал и в таком виде считать. Отличная идея, сам тож подумал что некузяво сейчас действую- заполняю Im нулями, и из результата только половина массива используется. Но так четко сформулировать не смог. :). Сейчас имею материалы как это сделать, но буду делать позже, на сегодняшний день работает, ну и ладно. Надо брать пример с Исимбаевой, которая планку чуть-чуть подымает и опять за новый мировой рекорд все заслуженные почести имеет. А прыгнула бы сразу на пол-метра выше- и все, карьере конец ;) Вот и я тоже, идеи есть, но если все сразу реализую- то завтра придется новые придумывать:) 4. Ошибка из-за подсовывания "псевдо-комплексного" сигнала (Im=0) комплексному БПФ: странно как-то. Постараюсь проверить, но в теории какая разница, ну легли у меня векторы на ось, почему это криминал? Но в-общем получилось неплохое исследование с удивившим результатом- после юстировки частоты кварцевого резонатора измеряемая частота (подавал с генератора синуса, контролировал частотомером) показывалась с ошибкой порядка 0.001 Гц. То есть можно говорить не о разрешении, а о точности такого порядка. Озадачило то, что все равно вижу разницу при измерении реального датчика (не генератора синусоиды) порядка 0.02 Гц между методом подсчета пересечений нуля и на базе FFT. Но проблема в том, что между измерениями есть промежуток 2 секунды, может просто датчик меняет свои показания. Проверил на Матлабе возможную дополнительную погрешность если входной сигнал не идеальный синус, а затухающая синусоида- получил очень малые отклонения (до 0.001Гц) при скорости затухания в десятки раз большей чем на моем датчике. Может быть кто-то может помочь с проверкой? Могу предоставить массив 24-битных семплов c АЦП, Хочу узнать точную частоту, которая получается при вычислении (любым Вашим методом) . Если будет отличаться от того что я насчитал- значит все-таки ошибка у меня в методе.

Неа, вроде бы не в этом дело. Прогнал на Матлабе, используя его встроенный fft и подсовывая идеальный синус (массив double). То есть как бы все считалась с большой точностью. Результаты таковы (подсовываю 823.15 Гц) Моя железяка (16-битовые целочисленные исходные данные и такие же целочисленные расчеты окна и fft) : 823.0948 Гц Матлаб, у которого и входной массив double, и все расчеты тоже в double : 823.0944 Гц. То есть переход от интов даже к даблам изменил результат на 0.0004 Гц. Вывод: дело не в точности а в стратегии. Что-то у меня с окном или с методом аппроксимации делать нужно. Может быть точность тоже вылезет, но сейчас она не виновата. (Сама аппроксимация в float32 делается, но все расчеты до нее целочисленные) PS. Однако сам слегка офигел от такой точности целочисленных вычислений. Причем выбранная частота далеко от бина.

Большое спасибо за совет! Попробовал подсунуть моему вычислителю 16-битный массив с идеальной синусоидой с частотой 823.150 Гц - получил результат 823.095 Гц. :( Бум копать, причем просто на PC в Билдере. Рано я к железу перешел, преждевременно :(

еще может интересно будет, насчет целочисленной реализации БПФ посмотрите вот это Вроде нареканий не было и чистый си, хоть куда лепится :) И очень экономно подходит к используемой памяти, как RAM так и ROM. Используются 16-битные знаковые числа. Очень удобно напрямую данные с АЦП подсовывать, ну или после нормирования, чтобы максимально использовать все биты.

В-общем, я получил положительный результат 1. Использую FFT8192 16-битную, с фиксированной точкой, 32150 SPS 2. Окно Хэмминга 3. параболическую интерполяцию в области максимального бина. результат очень замечательно болтается в диапазоне +/- 0.002 Гц :) Так что у меня 0.001 Гц resolution уже есть :) Вижу одну непонятку- разница по сравнению с методом подсчета периода составляет около 0.03 Гц. Сейчас не готов сказать кто прав, но пока что думаю что метод на базе FFT ошибается. Исходя из этого посоветуйте пожалуйста, какое из направлений более предпочтительно для улучшения результата: 1. Попробовать другое окно. Пока что пробовал без окна, Хээна и Хэмминга. Без окна жуть (на полгерца отличалось от метода измерения периода, болталось на те же пару 0.001Гц но около неправильного значения). Между Хэнном и Хэммингом разницы не заметил. 2. Попробовать перейти с 16-битных данных на 32-битные (у меня 24-битный АЦП, нормализую до максимально возможного 16-битного диапазона). Проблема- ОЗУ на FFT8192 в этом случае не зватит, только FFT4096 3. Попробовать перейти от целочисленного к плавающеточечному FFT. Опять же тогда осилю только FFT4096. 4. выбрать другой метод аппроксимации. 5. Оставить все как есть, списав на корпускулярные паразитные излучения из соседнего подпространства :) Благо нужный resolition уже достигнут, а новые хотелки в следующей итерации проверить, впаяв контроллер с бОльшей RAM. Понимаю, 5-й вариант всегда предпочтительной, но может можно что-то еще.....

Это к чему? предлагаете затребовать два года и 70 тысяч долларов за работу, которая делается за месяц? так опять же не поймут. И того крестьянина, который будет корову за пять мешков денег продавать тоже нормально не воспримут :) Нужно адекватно подходить, а не пытаться на разовую мелкую работу списать все затраты на образование и покупку всего инвентаря за последние 10 лет.

Здравствуйте! Есть отличное средство в MPLAB для визуализации данных, называется Data Monitor and Control Interface (DMCI). Но столкнулся с проблемой: он сдвигает на единицу ось X. Ниже поясняющий рисунок. Вывожу визуально величины из массива samples, на экран вывел первые 15 точек. Справа- тот же массив в числовой форме. реально имею samples[8] = 816 (выделено), а на графике это не восьмой, а девятый элемент (я к нему подвел курсор и видно, что значение в 9-й точке он показал как 816.000). Никто не сталкивался? при отладке свыкнуться с визуальной сдвижкой конечно можно, но как-то непонятно :( MPLAB 8.63

не видя исходников не сказать где передернули. 1. Можете посмотреть мой код. Писался в давние времена, когда еще IDE можно было с 8-битовым интерфейсом найти. Но реально юзалось с компакт-флеш и позже с СД-картами. fat16_example.zip 2. Сильно рекомендую, разобравшись где собака порылась, применить вот это (полный или урезанный вариант): FatFs Generic FAT File System Module http://elm-chan.org/fsw/ff/00index_e.html или Petit FAT File System Module http://elm-chan.org/fsw/ff/00index_p.html

А, ну да. 8.63, чего-то глянул на иконку 8.63 на экране, а руки 8.56 отстучали. странно :) Насчет PRO- я имел неприятности на PIC18 с этими версиями, 9.63 например, они иногда очень революционно оптимизировали, несмотря на volatile, разрушались данные в глобальных переменных (массивы в несколько килобайт). Надеялся что глюк в руках- не нашел. Откатился обратно на STD. Думаю что логика у них одинаково сделана для разных семейств, вот и обхожу PRO стороной, не стоит оно того (ну или может уровень написания моих программ недостаточен для PRO, но в-общем не срослось у нас :)

1. как я понял, у вас уже все идет. поздравляю. :) 2. Если глючит на такой программе- то что-то с установкой компилятора не так. Насколько я помню, у Хайтека есть что-то бесплатное, но с ограничениями. на попробовать вполне хватит. 3. Я сам PIC16 давно не пользовал, PIC18 их покрыли как бык овцу, но нареканий не было, и PIC18 с Хайтеком отлично работает (только не PRO!). Но вот если Вы собираетесь на что-то более современное майкрочиповское переходить в перспективе- наверное лучше сразу Майкрочиповские компиляторы брать, Хайтек это тупик. Но вроде бы как раз для PIC16 и выбора нет, только hi-tech. 4. А чего МПЛАБ такой старый, вроде 8.56 уже есть. Если уж переставляете, то наверное новье не хуже старья будет :)

Какое семейство и какой компилятор? надеюсь не PRO ? для PIC18 #include <pic18.h> void main(void) { } для PIC16: #include <pic.h> void main(void) { } ну и конечно в мплабе семейство соответствующее выбрать нужно.

А Вы действительно считаете, что в своей деятельности так и будете применять именно те элементы и именно те программы, в которых Вас научат кнопки нажимать? Самое супер-пупер-завтрашнее два раза устареть успеет за первые 10 лет Вашей будущей работы. А на старом проще учиться, там все виднее и оптимальнее делалось, избытка вычислительной мощности не наблюдалось. Ну и пусть ферритовое колечко там видное невооруженным глазом вместо рамтроновского FRAM- ну и что :) Про литературу так вообще, самые крутые книги написаны до нашего рождения, а "XXX за NN дней" это не учебники а губители мысли. Они не объясняют почему а просто говорят как. А что сейчас такое ненужно-старое дают, если не секрет? Секционные процессоры? Трехуровневую логику? Аналоговые ВМ ?

Ну это нормально уже стало, писать "требуется на работу инженер, знание ЕСКД приветствуется". Значит существуют инженеры и не видевшие никогда ЕСКД :-)

1. Неа, не удивился. Сам конечно тож не участвовал ни в стерео ни в 3D, но и не объявляю сроки разработки для процессов, в которых не шарю. Просто если плату еще возможно технологически за 2 дня сделать (хотя может Вам картонка тоже годится, не знаю). То заказ деталей и их ожидание занимает время. Может возникнуть счастливое стечение обстоятельств, когда множества "разработчик" и "наличествующие детали" удачно перерсекутся, но это точно будет оптимально для Вас только по критерию "время", так как остальные параметры устройства определятся наличной элементной базой. 2. Заказ деталей. У вас там уже рассосались проблемы с DHL и иже с ними? можете что-то заказать и через 2 дня получить на пороге? Просто интересно, помню прошлым летом вообще что-то ненормальное с вбросом в Россию DHL посылок творилось. Да и потеряться может всегда. Ну да, перепошлют с извинениями, но сроки-то уже тю-тю. 3. Ну и собственно разработка. И отладка на столе. И тестирование в поле. И изменение софта-харда по результатам тестирования. И апдейт документации на эти изменения. Из своих умозаключений и Ваших сроков у меня сложилось мнение, что в любом случае Вы собираетесь не оплачивать собственно разработку, она в эти две недели не влезет. Подразумевается, что исполнитель уже к моменту начала договорных "двух недель" уже имеет готовое решение. С готовым решением это не маги и чародеи, а люди которые в теме и могут второй раз продать ранее разработанное. :) Я ж ничем не рискуя могу что хотите написать, не найдутся умельцы за две недели разработать и прототипирование сделать :) А вот это уже реально, тут согласен. сам делал небольшие проекты с нуля с десятком устройств. Да и то не с нуля, а на базе опенсорца. Но с честными разработками железа и ожиданием комплектухи и изготовлением плат включительно. То есть если человек представляет о чем речь идет- то да, за 5 недель сварганить может. Но это опять же некоторое везение нужно.

И снова зравствуйте! :) Всех поздравляю с прошедшими праздниками, начиная с нового нового и старого нового годов и до 8-го марта включительно :) Вот и добрался я до поля мной непаханного, а именно до вычисления частоты не подсчетом переходов через нуль, а методами ЦОС. Напомню чего лично мне хочется: Вид сигнала- единственная затухающая синусоида (колебание струны) Диапазон частот входного сигнала- 400-6500 Hz (ну может от 100 Hz, но сейчас не нужно). Длительность выборки- 300 ms Цель номер раз: определить частоту сигнала с разрешающей способностью 0.001 Hz. Все остальные параметры сигнала (амплитуда например) сейчас не интересуют. Шумы специально не оговариваются, с увеличением оных разрешающая способность может (и как я понимаю будет) падать, не проблема. Другой вопрс что я уже сейчас вижу не 1. Поставил (наконец-то) Матлаб, 2. оцифровал реальный сигнал через вход Sound Card. Использовал разную частоту семплирования, но всегда 4096 сэмплов. Все точки сэмплирования являются значащими (то есть синусоида присутствует и нет дополнительных шумов связанных с ее возбуждением). Входной сигнал имеет частоту в окресности 820.2 Hz 3 вычислил FFT. Ниже приведена картинка вычисленного. Четко виден основной сигнал на 820 Hz и его третья гармоника на 2460 Hz. Также видна палка на пятой гармонике (4100 Hz). палка около 4600 Hz- это шумы преобразователя питания реальной схемы, будем бороться. Что-то из шума наверняка является приветом от звуковой карты, которая и оцифровывает. Некоторые вопросы: 1. Я специально никаких окон не задавал, Как я прочитал, матлаб по умолчанию не использует оконных функций, "размывающих" спектр основной палки. Как я понял, окно нужно выбирать в соответствии с тем, какой метод будет использоваться для уточнения частоты. Так ли это? 2. Потерялся в методах. Первый этап понятен- беру FFT и нахожу область, в которой буду делать уточнение (+/- половина максимального бина). А вот дальше туплю. Единственное что понял- математику не тяну :(. То есть из теоретической статьи написать m-файл чтобы посмотреть в работе, не смогу. Так сказать, определил пределы своих способностей :( Может быть у кого-то есть матлабовские примеры на этот счет, чтобы глянуть, или ссылки на статьи для практикующих инженеров, которые плохо и давно учили ЦОС? Сейчас вот открыл пару десятков закладок, в том числе и электроникса, обсуждалось уже тут подобное. Может умнее стану когда прочитаю........... В-общем, определяюсь с методом и нану копать интернет на предмет доступной моему пониманию практической реализации. пока что самое мне понятное, это рекомендации fontp (http://electronix.ru/forum/index.php?showtopic=80460)

Скажите, Вы, лично Вы когда-либо участвовали в реализвции каких-либо проектов, которые делаются с применением электронных деталек, к тому же программируемых? Или хоть стояли рядом во время сего действа? Если кто-то сделает за две недели разработку, прототипирование и документацию - напишите мне в личку, пожалуйста. Такие люди нужны. Думаю, смогу найти постоянную загрузку для мага и чародея такой квалификации. Исключение- случай, если в течении нескольких недель подготовки техзадания будет выполнена работа по рисованию схем, заказу печатной платы и комплектухи, а техзадание будет представлять собой на 99% готовую выходную документацию. Тогда все неинтересно и тривиально.

Разобрался вроде. Матлаб стоит и работает, данные с линейного входа саундкарты записываются в файл и показываются на экране. Хватило внятно откомментированного m-файла, который я использовал как прототип: http://www.mathworks.com/matlabcentral/fx_...d_acquisition.m Ура! теперь и я в теме.... :) PS вы не думайте, я не 4 часа качал матлаб и разбирался. Дети, ужин....

Оговорюсь что я Матлабом только чуть пользовался, запуская чужие приложения по инструкции. То есть нуль полный, учу нужные кусочки системы в боевых условиях. Загорелось мне именно то, что тут обсуждается. Скажите пожалуйста, вот этот путь правильный? Мне нужно оцифровать данные (сигнал звукового диапазона) и дальше поиграться с обработкой. Я ставлю Матлаб и Data Acquisition Toolbox и будет мне счастье? Нашел тут разжеванное описание ("Acquiring Data with a Sound Card", эту инструкцию я повторить смогу :) http://www.mathworks.com/products/daq/demo...iring_data.html Правда я пока не понял, какие звуковушки поддерживаюстя, какие нет. У меня ноутбук, не новый но делл. боюсь что засада может быть. Но как я понимаю в любом случае не проблема подсунуть Матлабу скажем оцифрованный штатным виндовым рекордером файл. Это правильно? PS. Сейчас доищу поиском на форуме, вдруг тривиальные вопросы задаю....... PPS Млин, и сколько интересного мимо пролетает на что времени нету, но хочется изучить и юзать.... Не пойму, чему вообще в институте учили, куда ни плюнь- так этому тоже не учили.....ну да, не было тогда компов для матлаба, разве что. Хотя наверное на топовой 386-й тоже что-то тогда крутилось, но нам не показывали.....

Ну что вы все право как-то совсем по-взрослому вопрос поставили. Тысячные тиражи, Китай, окупаемость.... Да не нашего с вами это ума дело! Где вы видете в предложенном ТЗ что-то кроме проведения разработки и изготовления опытного образца? Ну ведь простенькое устройство, за пару сотен часов со свистом разрабатывается и плата и софт. Опытный образец слабать- ну себестоимость платы с подготовкой производства долларов в 100-150. Комплектуху надо считать но на первый взгляд в 200 долларов уложиться можно, вместе в пластмассовой коробочкой подходящего размера (у нас больше Польша и Италия, до 5 баксов можно конфетку подобрать из имеющегося на базаре). То есть стоимость разработки будет скажем 350$ плюс зарплата хорошего спеца за месяц. Я не говорю про торонты с ванкуверами, за сколько адекватный микроконтроллерщик на пространстве СНГ эту конструкцию выходного дня сделает, тысяч за пять зеленых? за три тысячи? Сроки 2 месяца от пожатия рук до обмена денег на прибор, ну не вижу я что тут дольше делать. НО! :) Один крупный вопрос к топикстартеру это документация. "Разработка документации на производство по принципиальной схеме" - такого понятия я еще в ЕСКД не встречал. Уважаемый заказчик уверен что он реально требует от разработчика изготовления всего того шкафа документации, который подразумевается в ЕСКД? Если да, то упомянутую мной сумму нужно смело умножать на N или все-таки умерить аппетиты заказчика. Или разбить задачу на две- первая это разработка прототипа и его документирование на уровне "как это работает" и вторая задача это производственная документация.

Не советовал бы использовать SDcard для хранения файла подкачки. Это не винчестер, у флэша ресурс по количеству записей ограничен.