forever failure

Благодарю за помощь, по вопросу 2 всё получилось. Тем не менее, по вопросу 1 таки хотелось бы узнать реальный опыт использования данной конкретной модели со следующими возможными вариантами ответов: - "Да, выше 1 км высота определяется корректно" - значит разрабочики накосячили в документации; - "Нет, выше 1 км высота не определяется" - ну тоже понятно кто куда руки приложил. Советам по быстрому переразвести/перепаять/заменить на что-то прошу тему не загружать.

Здравствуте, уважаемые. По сабжевому GPS приёмнику, точнее по формату его выходных данных возникло несколько вопросов. 1. В строке географических координат (префикс $GPGGA ) для поля превышения выделено 5 знаков (по даташиту), при этом максимально возножное значение указано равным 999.99 м. При этом в даташите на сам чип указана максимальная высота в 18000 м. Есть ли возможность определять превышение на высотах более 1 км, и если есть, как это реализовать? 2. Кроме времени UTC требуется ещё и дата (т. е. число, месяц, год), однако какой командой её получить (или выводить в секундном сообщении) - нигде в даташите не нашёл. 3. В проприетарных командах некоторые команды идут с завершающей контрольной суммой, - некоторые без неё. Тут всё в порядке ? Такое построение протокола на какой логике основано ? В общем, хотелось бы получить помощь от тех, у кого есть опыт работы с данным приёнмиком, в основном по 1 и 2 вопроосу.

В плоском С не может, в С++ может, должно и работает именно в таком виде.

ээээ.... То есть на адуке завелась новая форма жизни в виде искусственного интеллекта ? Ну и про 9 бит - а принимающая сторона способна такую посылку проглотить ? Да и 11 % отклонения по скорости - эт пожалуй за пределами возможностей последовательного порта. Но, если у автора принимающая программа крутится под виндой, есть ход конём на кривой кобыле: на адуке выставить нестандартное значение скорости, которое устраивает и на принимающей программе тоже в коде инициализации ком порта подставить полученное значение скорости.

Тут автор видимо не упомянул, что согласно даташиту сабжевый контроллер имеет на борту ПЛЛку и делитель частоты, и наружу у него торчат ноги для поключения _часового_ кварца (32768 Гц) и другие варианты выбора источника тактовой частоты не предусмотрены. Поэтому использовать кварц с частотой 11.05092 МГц весьма проблематично, если вообще возможно. Проверка ошибок фрейма/чётности/переполнения буфера в WinAPI: bool frame_error = false; DWORD err; /* ... */ ReadFile (/*...*/); /* тут ваше чтение байта */ ClearCommError (handle, &err, 0); if (err & (CE_FRAME | CE_RXPARITY | CE_IOE | CE_OVERRUN)) frame_error = true; /* ошибка обнаружена */

Подскажите, плз, у кого есть такой опыт - как работает сабжевый ОУ при +/- 5 В питания ? По даташиту operational напряжение питания от 4.8 В, но все характеристики приведены для +/- 15 В. Сильно ли меняются основные характеристики при снижении питающего напряжения ?

Да именно так, похоже неверным оказывается printf

Пробую телепатировать: должно получится 66467.6, нет, не так ? Если так, то ваш линукс и иполняемое приложение должно исползовать little endian порядок байт. Иначе пробуйте заполнять выше обозначенный унион в обратном порядке: value.bytes[3] = data[4]; value.bytes[2] = data[3]; value.bytes[1] = data[6]; value.bytes[0] = data[5];

Ну а на другом конце модбаса эти отмеченные болдом байты из чего берутся ? И: верность числа в чём заключается ? А так, в качестве опыта, - подставьте ваши болдом выделенные баты в любой хекс-эдитор, и посмотите, какому значению четырёхбайтной плавучки эти байты соответствуют.

Про тему пардон, в шары долблюсь. Верно - это как ? Они из каких данных составляются, в коде покажите. Ну и опять же на АРМе порядок следования байт может быть любым. Он одинаков на обоих сторонах модбаса ?

1. Каким образом первоначально формируются эти четыре байта ? 2. Порядок следования байт (little/big) endian, не ? 3. Тема целевой платформы, на которой происходит выполнение не раскрыта.

ТермоЭДС ? Опорник AD780 сильно не греется, скорее всего DC-DC преобразователь.

Догадываюсь, но специально не выяснял, потому что, повторюсь - было не критично, и на результат (высокочастотные измерения) никак не влияло. Скорее всего - рядом с АЦП были расположены две HCPL2430, которые прилично так топятся в рабочем режиме, и они-то и создавали термоградиент.

Чо-то где-то дрейфует или термоЭДС (наиболее вероятно). У меня девайс на ads1252 через полчаса прогрева на 200 мкВ уходил, а если просто внутрь подуть видно было, как на 2-3 мкВ смещалось сразу же. Правда, в моём случае это было некритично. У техасов в даташитах на некоторые ОУ, (и может и на АЦП) есть рекомендации по компоновке и расположению элементов на пп с целью минимизации разного рода дрейфов и паразитных ЭДС микровольтовых величин. Если требуется микровольтная стабильность - такие рекомендации тоже надо соблюдать неукоснительно.

Что говорит тов. осциллограф ? Иногда в "проверенных временем программах" обращение к последовательному порту реализовано не через вызовы функциф АПИ, а через прибитые на гвозди прямые обращения к портам/регистрам контроллера ПП. Правда, в этом случае, скорее всего просто бы не заработало.