Сделайте ему чтоль cold start… Ну и лог сообщений лучше покажите.
А где его достать? Есть только лог NMEA, но там ничего полезного.
Пункт u-blox 7/M8 Retrieve Log… очевидно не подходит для 6M.
Dump Receiver Diagnostics даёт бинарный файл, который я не понимаю, как расшифровать.
Заметил интересную особенность: всё заработало, когда отправил комп в спящий режим. Разбудив комп обратно - узрел растущий Accuracy, за которым последовал снова No fix.
Грешил на наводки по питанию, и китайцев, которые сэкономили на конденсаторах. Допаял по кондеру до и после стабилизатора, разницы не заметил - No fix.
Отсоедилинил Rx провод от UART конвертера (так сказать, оставил в режиме чтения), и через некоторое время ожило. Эксперимент прервал BSOD, после которого я вспомнил, почему я CH341 не использовал в URART режиме под ХР 
(но, надо отдать должное, как I2C адаптер CH341 ведёт себя отлично)
Дубль два - PL-2303. GPS заработал, винда не вываливается, но где-то спустя минуту передача данных виснет, приходится жать Disconnect, и конектить обратно. Странно, раньше такого за ним не наблюдал. Ладно, в сторону.
Берём старый проверенный FT232RL, подключаем… Полёт нормальный!
Читателя наверняка заинтересовало, почему я не взял плату с USB, и зачем все эти извращения. Отвечаем: задача стояла взять приёмник, который можно будет потом воткнуть в ардуины и т.п. Т.е. нужен именно UART. И чтобы не было сюрпризов - работать сразу начал именно с ним.
Итак, имеется приёмник ublox6 версии 7.03.
Нашёл команду для включения RXM-RAW. Включил, работает. Теперь вопросы:
- Можно ли на нём включить RXM-SFRB? Если да, то как?
- Если нет, то как включить TRK-SFRB? u-center о таком сообщении вообще не знает.
Попробовал, работает. Поставил measurement period 200мс, теперь у меня на выходе 5гц… Но, внезапно, и частота решений тоже стала 5гц! А в описании было, что 1гц только. Интересно 
- Значит ли это, что я действительно получил частоту решений в 5гц, или это лишь видимость?
- Так и не понял, как сделать частоту решений и частоту сырых данных разными. Предполагаю, что для этого надо увеличить navigation rate до 5 циклов, но он не даёт ставить ничего отличное от 1.
- Я правильно понимаю, что поставить UBX-CFG-SBAS Subsystem=disabled будет достаточно?
Про логи - ну там есть text console, binary console, packet console.
Да, для отключения sbas упомянутого выше должно быть достаточно.
Я использовал http://jkdevices.com/jkd-usb-ttl - это тоже FT232.
Serial output еще прекрасно подходит для прикручивания OpenLog. Если приемник помнит конфигурацию, то можно не таскать с собой ноут на улицу.
Нужно ли производить какие-то дополнительные действия для того, чтобы конфигурация запомнилась?
На плате есть батарейка, но конфигурация почему-то каждый раз сбрасывается… Она не для этого?
Я в этом вопросе не очень разобрался. В том девайсе что мне достался, конфиг сохранялся сам собой без всяких батареек - там SPI Flash вроде имеется. Сохранялось вообще все, включая набор сообщений и прочее.
Есть в uCenter такая штука как Receiver->Action->Save config. Попробуйте.
Попробовал, работает.
Это хорошо, что сам не сохраняет. Я уже терял связь с устройством, когда проверял, какую максимальную скорость порт поддерживает Если б он сохранял конфиг автоматом - не знаю, что бы делал.
Делал бы reset.
Хотя я бы тоже это предпочел, с батарейкой. На Antaris4 - 115200, этого достаточно для 10Hz сырых данных.
У меня по дефолту вообще 9600 стояло. Так что первым делом сменил на 115200. Ещё пробовал 230400, работает отлично. Только почему-то Ozi такую скорость не понимает Но это уже его личные проблемы, остальной софт ок.
А вот 460800 уже не прокатило.
Так что, возможно с него получить RXM-SFRB, или нет?
Это уж не ко мне
-1
-1
-1
Фраза достойна сочинения на тему “что хотел сказать автор” 
(и при чём тут вообще windows…)
Разве не вы писали, что ublox 6 уже успешно тестировали с rtklib? Или вместо RXM-SFRB был использован TRK-SFRB?
-1
Ну, по крайней мере, сообщения появились. Теперь осталось понять, что с ними делать
Подключил rtknavi в режиме чисто ровера (без базы). Решения не выдаёт… Или он так не работает?
Тип 1 использовался в двух случаях:
а) аппаратный приемник понимает только этот тип;
б) канал передачи данных имеет скорость 100-300 bps;
Поясню как формируется Type 1 и 2.
Type 1:
- Базовый приемник делает измерение дальностей;
- Корректирует измеренные дальности на ионосферные, тропосферные и прочие задержки по информации из broadcast data;
- Считает положение спутников по информации из broadcast ephemeris;
- Считает разность по каждому спутнику и её дрейф, формирует сообщение Type 1 PRC[m] и RRC[m/s];
Т.е. тип 1 подразумевает что эфемериды и модель атмосферы должны быть бродкастными на базовой станции и ровере. Номер эпохи navdata указывается отдельным полем в Type 1; использовать ultrarapid SP3 не получится (точнее можно, но это будет уже какой-то custom RTCM )))
Type 2:
Когда на спутник закачиваются новые navdata то может возникнуть короткое окно, когда базовый приемник уже обновился и формирует обновленные Type 1, а ровер всё ещё использует старые navdata (например слишком слабый сигнал, или спутник над горизонтом, или временно прерывался сигнал). Type 2 как раз и есть разница между двумя коррекциями Type 1 если они считаются по разным навигационным данным.
Кстати ровер тоже должен хранить два сета navdata на случай если обновился раньше базы.
В общем слишком сложно для базовой станции и требует хранить два массива navdata как на базе, так и на ровере.
Так что в ситуации realtime через скоростные каналы связи (9600+ bps) лучше использовать Type 19 - raw pseudorange, они обеспечат более качественный результат, не требуют нагрузки на базу, не требуют привязки к бродкастной модели атмосферы и эфемеридам.
-1