Ruslan1

кстати 1258 я тоже применял, очень неплохой АЦП для своего круга медленных и неодновременносемплируемых задач. Насчет 1255- так там один канал-то. Так что я из тех получился кому "итд" перевесило шумы. Зарубку на память конечно поставил, что, изменив схему и фирмварю так-то, можно увеличить SNR, но дальше зарубки дело не пошло. Также и с температурой- кому как, 210 это конечно круто, но для узкого круга крутых профессионалов :)

года три назад я заказывал семплы ads1281 и 1282. Реально игрался кажется только с 1281. Результаты не впечатлили. Да, SNR примерно в два раза лучше стало, но, учитывая удобство применения(у него даже CS нету в интерфейсе!) и цену, все-таки остались на ADS1255.

Если не жалко, напишите что за программатор в результате собрали(я так понял что KovPIC), какой софт для программатора использовали и что в этом софте конфигурировали. Вдруг еще кому-нибудь эта инфа в будущем поможет, может даже вам самому :) У меня было подобное: подробно расписывал в Фидонете как например компилятор правильно поставить. Когда через годик пришлось повторять процедуру установки- нашел свое же письмо в базе конференции и с его помощью быстро все поставил :)

Вы сказали что это невозможно, я вам привел конкретный пример. Вы же не сказали условия невозможности :) (ну да это просто бессмысленная пикировка, думаю дискутировать на эту тему бессмысленно, возможно-невозможно. Да возможно но при определенных номиналах схемы и требованиях к диапазону.) Но я надеюсь, вы также и не делаете общим проводом датчиков плюс питания? :) Хотя это тоже довольно часто встречается в релейных схемах на объектах: +27 вольт подается на все реле, а второй контакт реле на измеритель. Согласен с вами про соединение заземления с общим проводом прибора. Но к сожалению часто обстоятельства от нас не зависят, и приходить в чужой монастырь со своей концепцией "если датчик одним концом вмурован в GND, то мое устройство с ним не работает" мягко говоря опрометчиво.

Вот! Это оно! Реально нужно-то плясать от того момента когда изображение на экране появилось, а не когда софт его в вроде бы отправил на дисплей. Сто пудов хорошее решение, все остальные варианты синхронизации с изображением- это действительно лотерея(вероятностный процесс) Кстати, есть такая фирма Tiny Love, делает игрушки которые в соответствии с видеорядом на экране гавкают-мяукают в нужное время. Так там просто в начале мультика идет кодовая посылка (но кажется звуковая), по которой игрушка синхронизируется и дальше гавкает в нужное время. Может и вам достаточно чего-то подобного, разовой синхронизации в начале непрерывного теста, а не ловить каждый кадр.

Тогда сразу настраивайтесь на сопровождение передаваемых данных маркером времени. То есть часы контроллера (на котором нажимают-крутят) и компьютера синхронизируются с точностью до 1мс (может, с помощью другого интерфейса, например стандартный сигнал 1PPS). Далее все данные сопровождаются временем их съема. Таким образом, нужная вам точность будет обеспечена при любых задержках интерфейса. А вот максимальная задержка интерфейса уже определяется тем, как быстро вам нужно обработать данные (20мс). Тонкое место- это синхронизация всех измерителей с такой точностью. Если с контроллером все более-менее решаемо, то с IBM PC даже не знаю. Проще наверное напрямую этим же контроллером начало кадра выделять и в попугаях кадрах и считать всю времянку Кстати, это какой такой системой РВ на IBM PC вы миллисекунды считать будете? и что, привязку к началу развертывания кадра можно сделать? Я не покдкалываю, действительно интересно. Делали когда-то распределенные системы для определения порядка срабатывания тысяч реле, шаг времени был 1мс, вот и интересно можно ли сейчас это без хитрых инженерных выкрутасов, а только засчет шустрой техники достигнуть.

Ну отчего же, взгляните на первую попавшуюся таблицу. Измеряемое напряжение от 4.9V до 0.09V, вполне себе полная шкала 5-вольтового АЦП. Как правило(всегда), лучше с платы выводить землю чем провод питания. То есть если вы работаете в пределах платы- то это не так критично. А вот если датчик подключен к плате как внешний- то сильно советую чтобы одним из сигналов была GND, а не U+. Если именно U+ позарез необходимо выводить- то поставьте последовательно токоограничивающий резистор для защиты источника питания от замыканий проводки датчика на общий прибора. Лично я вижу потенциальные преимущества в подключении датчика к GND и при прочих равных буду делать только так. Причина описана выше- наружу лучше выводить GND, поэтому всегда датчик подключен к GND, чтобы не множить сущности.

Угу. Я сейчас на многое так смотрю и думаю блин был холостой без детей- на что время тратил..... Хотя с другой стороны не так уж все зря было.... опыт не пропьешь и не купишь... В выходные сотни полторы CD-дисков с даташитами и софтом на помойку из квартиры вынес..... дальше на очереди шкаф с книгами.... Мда. вот там где у вас аналог девайс в пикстарте от 5v просматривается, я отечественные КН впаивал, с чем много позже и имел проблемы.

А на будущее- поднакопите денег и купите PICkit3 (три а не два!). В самом запущенном случае (Если в Digi-key покупать), это обойдется в 45$(программатор)+30$(пересылка). Это как репер по цене сверху, наверное у локальных представителей можно в сумме дешевле купить. Ну или собрать его же, если свое время ничего не стоит. В результате будете иметь USB программатор и дебаггер(отладчик) в одном флаконе, официально поддерживаемый майкрочипом и умеющий программировать практически все их кристаллы. Причем список постоянно расширяется с появлением новых контроллеров. Сейчас тенденция уходить от 5-вольтового питания, так что сфера применения вашего JDM сужается. Я уж не говорю про отладчик и скорость/удобство работы с USB. Если вам для долговременного пользования- то иметь PICkit3 это очень эффективное решение в плане цена/качество. Ну а если все-ж таки просто самодельный программатор- то опять же USB собирайте. Мне GTP-USB-lite понравился, хорошо и устойчиво работал, но с довольно ограниченным набором программируемых камней. говорят что он близок к PICkit2. О да! Я COMPIC-1 уже давно подарил, а вот PICSTART у меня в пределах 5-минутных поисков болтается, спасал меня пару раз :). Причем делал неплюсатый (На PIC17C), потом много позже докупил майкрочиповский апгрейд к нему, теперь он "+" :) Есть конечно свои заморочки, но именно потому что самодельщина- был бы умнее когда молодой был, не ставил бы отечественные микросхемы унутрь.

А просто проверьте тестером (конечно без вставленного ПИКа), там справа есть чекбоксы для тестирования. Ставите галку и смотрите тестером действительно ли этот сигнал стал активным на панельке ПИКа (минус тестера подключаете именно к общему на панельке ПИКа а не общему компьютера!). Заодно и проконтролируете какие напряжения он выдает и вообще выдает ли. насколько я вижу, в вашей схеме (KovPic): Data out- с инверсией Clock- тоже Vdd и Vpp - тоже Data in - без инверсии Приемные данные опять же тестером на ногах RS-232 проверить можете, между общим компьютера (5 нога) и 8.

Хм. Ошибся. зачеркните. (Подумалось что так как нет точки запятой то он delay включил в тело цикла, и эти goto как раз и есть delay). Просто я никогда не пропускал разделительную точку с запятой, которая у вас отсутствует, вот и подумал что непонятный эффект из-за этого. Оказалось, что неправ (счас поверил, правдо на хайтече для 18-х, но это непринципиально. но для 18-х он goto не вставляет). А у вас он похоже просто выравнивание по циклам делает. Приходится догадываться что от чего сгенерилось, если бы вы могли просто кусок листинга привести- было бы проще (View->Disassembly Listing в МПЛАБе)

нет, они полностью соответствуют while(GP0==1){}; или while(GP0==1); Найдите разницу. На будущее, если вы склонны делать ошибки типа "=" вместо "==" и не обращать внимание на варнинги, лучше в операторах сравнения слева пишите константу а справа переменную, тогда компилятор сразу покажет плохое место. то есть while(1==GP0){}; Общее замечание: каждый возникший при компиляции варнинг должен быть рассмотрен и по возможности исправлен. Часто встречал случаи, когда неправильно работающая программа после "работы над варнингами" начинала работать так как хотелось автору этой программы, и компилятор тут не виноват.

Я тоже. Напряжение на выводах RS-232 +12/-12, в сумме размах от плюса до минуса 24вольта. Понятно, что сейчас размах напряжения обычно меньше чем был при коммунизме и PC/386, но все равно достаточное. Посмотрите внимательно: общий компьютера это 5-й контакт 9-контактного разъема RS232. 1.Vss(общий) программируемого кристалла подключен к отрицательному напряжению, которое формируется после выпрямления сигнала на 4-й ноге разъема rs232. (Правильнее использовать многофазный выпрямитель как в COMPIC-1, а еще лучше- внешний источник питания). 2. Vdd (5 вольт ПИКа) это общий RS232. величина напряжения между Vdd и Vss стабилизировано стабилитроном D3. 3. Vpp (напряжение программирования, c точки зрения ПИКа прикладывается между Vss и Vpp) это напряжение от Vdd до Vpp плюс напряжение от Vss до Vdd. оно равно сумме напряжений стабилизации стабилитронов D2 и D3 плюс падение напряжения на D1. PS Нет, COMPIC-1 c его многофазным выпрямителем и 78L05/78L12 смотрелся все-таки лучше. Но и это работать должно хорошо.

Перечитайте мое сообщение, после слов "обратите внимание". Про транзистор- если по структуре и предельным уровням напряжения подходит то почему бы нет.

Где купить GPS модуль с антенной за 15 баксов? Или это цена в поднебесной без стоимости доставки и на партию в 100 штук?

Есть некоторые соверщенно непонятные мне вещи в приведенной схеме, работает оно наверное только благодаря неубиваемости ПИКов. После фразы дальше читать не хочется. Человек, который не смог запустить очень грамотно сделанный несмотря на простоту JDM программатор, почему-то доволен схемой, в которой напряжение программирования устанавливается последовательно включенным в цепь Vpp подстроечником. Сильно не советую повторять такую схему и пользоваться ей (само название ресурса "радиохлам" должно насторожить :) Лично я JDM (COMPIC-1 с модификациями) наверное десять лет использовал, никаких проблем. Конечно, питание внешнее, конечно полевик в цепь питания для должного порядка подачи напряжений, но это тот же JDM. Попробуйте найти версию JDM под названием KOVPIC, с полевиком (Вроде на казусе есть ссылки, но у меня сейчас чего-то этот казус не открывается) Есть куча фриварных оболочек программаторов, в списке которых есть JDM, уверен что и под семерку найти можно. родной COMPIC-1, грамотная схема.. Именно от такой схемы и советую отталкиваться. Обратите внимание, что земля программируемого камня и компьютера не совпадают.

Из сугубо личного опыта, CAN очень чувствителен к параметрам линии (и это объяснимо), RS-485 намного дубовей и всеядней. 38400 на несколько километров по нелиниям связи со свистом бегает. Зато у CAN (я говорю про CANopen протокол) стандартизирована атоматическая раздача адресов и автоопределение скорости, вещи очень удобные если часто что-то подключается-переносится. Велосипед не нужен, достаточно реализации стандартного Модбаса с его 256 устройствами на линии. просто хаб это тоже одно из устройств, ему приходит команда- он коммутирует компьютер на нужный луч со своими двумя сотнями точек. Обязательно нужно предусмотреть вторичную проверку, правильно ли произошла коммутация, это можно сделать на уровне пользовательского приложения, не трогая протокол(в контроллере один из Модбас-регистров хранит этот персональный неповторяющийся ID, который всегда спрашивается и присутствует как данные в составе пакета данных принятого от слейва). Применение стандартных технологий дает массу возможностей в будущем, в любой момент можете купить какую-нибудь примочку (ну скажем, выйти на езернет или радио-удлинить какой-нибудь кусок вашей сети). Аппетит придет во время еды и лучше быть к этому готовым :) Насчет все контроллеры(каналы связи)в один порт PC: планируете узкое место в самом дешевом разовом участке сети, в центре. Если можно разложить на порты по скажем максимум 256 устройств на порт, то тот же Модбас вообще без выкрутасов и коммутаторов потянет (правильнее кажется 240 устройств, остальные адреса зарезервированы стандартом). Чем меньше "умных" устройств между центром и сенсором-тем спокойней спать будете. Многопортовка не такая дорогая вещь, а распараллеливание медленных процессов (связь) это всегда хорошо. Крайне не советую делать доморощенный протокол, получится очередная вещь в себе, тупиковая ветвь эволюции.

(Просто комментарий, извините.) Вам точно зададут вопрос про предельное количество устройств и требуемый объем данных для обмена. Также СЕРЬЕЗНО подумайте над вопросом кто является инициатором связи. У Вас написано что "Со стороны PC необходимо получать не только сигнал, но понимать какой из датчиков его выдал". То есть инициатива датчиков? Это еще туда-сюда на CAN, но вот при беспроводной реализации проблемы создает крупные по времени доступа и оверхеду траффика. По закону подлости всем датчикам приспичит свистнуть одновременно. Ну не знаю, может в России все и хорошо (на каком чистом полигоне интересно они 10км на 433МГц 10mW получили?), но в Москве и окрестностях эти расстояния думаю так в сотню-тысячу раз уменьшить нужно. Ну и мне кажется, вам лучше ориентировать потенциального разработчика системы на взять что-то готовое (протокол хотя бы) и реализовать его, а не придумывать очередной доморощенный велосипед, задача классическая и решения нужны классические а не придуманные вчера. Если дело ограничется написанием(разработкой) простенького интерфейса с конкретными датчиками а не разработкой доморощенных протоколов и железа с нуля- вы только выиграете в результате. Не будет устраивать стоимость покупного-позже сделаете разработку своих аналогов для удешевления.

Очень актуально! И не зависит от природы данных, а зависит только от природы линии связи. Оборвался провод- пошли все FF, закоротился на землю- пошли все 0 (если данные и тактирование приемника по разным проводам). полином CRC должен быть такой, чтобы пакет вида 0,0,0,0,0 не был воспринят приемником как правильный пакет с переданным в конце CRC=0. Обычно это достигается тем, что начальное значение регистра CRC до рассчета не 0, а что-то иное. То есть если пакет номальный, то вы примете пакет "0,0,0,ненулеваяCRC", а если битый, то "0,0,0,0" и сможете отличить битый от небитого.

Еще один момент во время включения, может для большинства и очевидный, но я в свое время нарвался, хорошо до серии обнаружили и устранили. Если на плате стоит DC-DC с широким диапазоном входных напряжений, то ток при низком входном напряжении больше чем при высоком. Как результат- при возрастании напряжения во время включения ток потребления сильно выше чем при устоявшемся режиме. Жестко и грубо проявилось когда двадцать устройств посадил на 200-метровый кабель, через который они и запитаны. Питание поднялось до напряжения запуска DCDC, устройство начало жрать, ток вырос, падение на кабеле увеличилось, напряжение доходящее до устройств осталось маленьким, ток остался большим. Система стабилизируется и продолжает жить в этом непредусмотренном режиме. Медвежуть с подогревом кабеля и перегрузкой группового источника питания по току. Лечилось увеличением порога включения DCDC и размывкой момента запуска наплатной железяки (в зависимости от сетевого адреса контроллер начинает работать через разное количество сотен миллисекунд от ресета).

Опттимум у каждого свой. Одним кофеваркой управлять, другим многотонный двигатель мониторить. Если у Вас задана (В ТЗ например) вероятность обнаружения ошибки (или, что то же самое, требуемая вероятность принятия битого пакета за небитый), то исходя из этого можно четко сказать какой длины CRC нужно. Если на глазок пальцем направление ветра определяете (ТЗ молчит)- то берите CRC32 если ресурса хватает или CRC16 если не хватает. Применение более коротких CRC нужно уже обосновывать. По личному опыту- CRC16 совершенно хватает в промышленных масштабах (в составе MODBUS-RTU), пакеты от 5 до 256 байт. Дополнительно проверяется конечно и адрес и валидность информации представленной в служебных полях пакета, в-общем все то что уже содержится в модбасовском пакета. Для ваших коротких пакетов CRC32 все-таки еще тот оверхед. Берите CRC16. А может быть и CRC8, но тут уже считать нужно, хватит вам CRC8 или нет. И еще проверьте на передачу вырожденного пакета выбранный вами полином- скажем, чтобы пакет из одних FF или 00 не давал CRC равное тому же FF или 00, иначе такой мусорный пакет будет воспринят как нормальный. Это думаю вы уже видели и по ссылкам в конце ходили.

Фи! Вы им испытания для опытной партии делать собираетесь или таки просто использовать сенсор выпускаемый какими-то тиражами и уже имеющий статистику? (Думаю, нужную вам спецификацию еще не придумали) Не, меня малогабаритность интересует, чуда хочу. А если килограммы- так уж чем геофон хуже.

мне кажется, что лучше геофонов могут быть только геофоны :) А с всевозможными MEMS-датчиками можете для начала просто спектральную плотность шумов ("Output noise density" или подобное) смотреть, она в даташите приводится, ну и пересчитать для нужной вам полосы. А какие это "некоторые модели акселерометров с характеристиками подходящими для измерения микросейсмических колебаний" ?

Я извиняюсь за ортогональный обсуждению вопрос, но схема действительно рабочая? Ну, например мне глаз режет 51 Ом последовательно со светодиодом и болтающиеся в воздухе выводы SDC.

Что есть то есть. Но зато ассортимент! Стоимость доставки легко окупается если вы всякую мелочь у них и возьмете и все одной посылкой получите, а не будете по разным конторам бегать, упрашивая продать два резистора 0805 с точностью 0.1%. Удобство запросто может превысить те 35 баксов которые USPS за доставку их большой коробки берет.