Navilock собирается “в ближайшее время” выпустить приемники серии NL-82022MP
http://www.navilock.com/produkte/N_62755/merkmale.html?setLanguage=en
на базе NEO-M8U (урезанный DeadReckoning без внешних данных wheeltick, но с акселерометром+гироскопом Bosch BMI160).
Доступа к сырым GPS данным и прошивке там конечно нет
Обнаружились исходники для Huawei Mate 8
https://github.com/RaindropOS/android_kernel_huawei_next
а в них drivers/huawei_platform/connectivity/bcm/gps
https://github.com/RaindropOS/android_kernel_huawei_next/tree/c44a848caac35ac4ccc454b74cde24afe0806a13/drivers/huawei_platform/connectivity/bcm/gps
Это уже теплее.
ВСMGPS на этих устройствах на последовательном порту /dev/ttyAMA3
Хотел написать про железо и GPS на mate 9, но придется отложить на неделю. превед вертухаям.
Вопрос по языку программирования, известному как “write once, debug everywhere”.
андроид полностью падает вот с таким сообщением при использовании программы gnsslogger.apk ( https://github.com/google/gps-measurement-tools/tree/master/GNSSLogger ) :
art/runtime/indirect_reference_table.cc:138] JNI ERROR (app bug): local reference table overflow (max=512)
art/runtime/indirect_reference_table.cc:138] local reference table dump:
art/runtime/indirect_reference_table.cc:138] Last 10 entries (of 512):
art/runtime/indirect_reference_table.cc:138] 511: 0x13ecf000 java.lang.Class<android.location.GnssMeasurement>
art/runtime/indirect_reference_table.cc:138] 510: 0x136808a8 android.location.GnssMeasurement[] (7 elements)
art/runtime/indirect_reference_table.cc:138] 509: 0x13bd1400 byte[] (11 elements)
art/runtime/indirect_reference_table.cc:138] 508: 0x13bd1478 byte[] (11 elements)
art/runtime/indirect_reference_table.cc:138] 507: 0x13d1b900 byte[] (40 elements)
art/runtime/indirect_reference_table.cc:138] 506: 0x13d1b938 byte[] (40 elements)
art/runtime/indirect_reference_table.cc:138] 505: 0x13bd1670 byte[] (11 elements)
art/runtime/indirect_reference_table.cc:138] 504: 0x13bd1d78 byte[] (11 elements)
art/runtime/indirect_reference_table.cc:138] 503: 0x13bcb148 byte[] (11 elements)
art/runtime/indirect_reference_table.cc:138] 502: 0x13bcb1c0 byte[] (11 elements)
art/runtime/indirect_reference_table.cc:138] Summary:
art/runtime/indirect_reference_table.cc:138] 1 of android.location.GnssMeasurement[] (7 elements)
art/runtime/indirect_reference_table.cc:138] 1 of android.location.GnssClock
art/runtime/indirect_reference_table.cc:138] 2 of java.lang.Class (1 unique instances)
art/runtime/indirect_reference_table.cc:138] 390 of byte[] (11 elements) (390 unique instances)
art/runtime/indirect_reference_table.cc:138] 118 of byte[] (40 elements) (118 unique instances)
Вот эти “висячие” byte[40] и byte[11] это предыдущие навигационые subframes для GPS и глонаса соответственно,
которые и забили local reference table.
Может я чего недопонимаю в этом языке, но разве DeleteLocalRef в
https://android.googlesource.com/platform/frameworks/base/+/android-7.0.0_r30/services/core/jni/com_android_server_location_GnssLocationProvider.cpp
JNIEnv* env = AndroidRuntime::getJNIEnv();
jobject navigationMessage = translate_gnss_navigation_message(env, message);
env->CallVoidMethod(mCallbacksObj,
method_reportNavigationMessages,
navigationMessage);
env->DeleteLocalRef(navigationMessage);
должен “освободить” память под массивом, являющийся частью navigationMessage ?
На Mate 9 Galileo raw data работает, но как-то не очень здорово. Вот пример сырых данных для E14
Raw,2352904,92654000000,,,-1174133401345816604,0.0,6.3731318907790016,,,0,14,0.0,1074,2657120,7,37.32952117919922,-594.4398950144232,0.07155628388788515,1,-5963.906697538496,0.0010088905692100525,,,,,0,,6
I/NAV не видел, и это видимо связано с проблемой navigationMessage.
EGNOS тоже почему-то не дает никаких сырых данных, а Beidou я пока не пробовал:
для этого надо редактировать конфигурационный XML gps4774config.xml на readonly диске ( EnableBeidou=“true”)
<gll_features
EnableLowPowerPmm="true"
EnableOnChipMiCtrl="true"
EnableInternalBlanking="false"
EnableGalileo="true"
/>
Также было бы интересно отключить глонас, но совершенно непонятно как, и можно ли вообще это сделать.
Про C++ что ли?
Использование JNI требует аккуратности, как и всё остальное в мире C/C++.
Должен удалить локальную ссылку, сделав доступным объект для garbage collection. Проблема не в нём, а в методе JavaObject::callSetter:
template<>
void JavaObject::callSetter(const char* method_name, uint8_t* value, size_t size) {
jbyteArray array = env_->NewByteArray(size);
env_->SetByteArrayRegion(array, 0, size, (jbyte*) value);
jmethodID method = env_->GetMethodID(
clazz_,
method_name,
"([B)V");
env_->CallVoidMethod(object_, method, array);
}[/code]
При вызове NewByteArray создаётся локальная ссылка (array), но потом нигде не удаляется. При вызове из Java это не страшно, т.к. таблица локальных ссылок при возврате в Java очищается, а вот во всяких callback-механизмах это порождает утечки памяти.
OK, что делать ™ ? Написать логгер на c++ тоже будет непросто, хотя и по другим причинам.
Интересно, что все гуглопримеры по доступным ссылкам относятся к Qualcomm, а не к BCM477*, и везде показывают только “Raw” и нигде
“Nav”:
Nav,24,257,1,0,5,34,-61,-107,27,17,-128,-83,-69,20,-44,-30,86,19,-123,-117,81,63,81,0,24,40,67,54,-57,41,92,-54,-23,9,-126,103,-66,15,110,122,-104,47,64,2,-85
Nav,28,257,1,0,5,34,-61,-107,27,17,-128,-83,-69,20,-44,-30,-13,24,-59,-116,52,63,79,-64,55,40,67,54,49,41,90,-11,92,9,-125,-103,42,15,56,-29,-116,47,64,2,-85
Nav,30,257,1,0,5,34,-61,-107,27,17,-128,-83,-69,20,-44,-30,86,19,-123,-117,81,63,81,0,24,40,67,54,-57,41,92,-54,-23,9,-126,103,-66,15,110,122,-104,47,64,2,-85
глонасс тоже какой-то кривой (не редуцированный из FCN в SVN), поэтому у меня очень
глубокие сомнения, что он вообще используется в решении
Nav,93,769,1,0,7,56,116,56,121,30,52,-65,-11,-77,-13,120
Nav,96,769,1,0,7,56,116,56,121,30,52,-65,-11,-77,-13,120
Nav,98,769,1,0,7,56,116,56,121,30,52,-65,-11,-77,-13,120
Nav,105,769,1,0,7,56,116,56,121,30,52,-65,-11,-77,-13,120
Nav,106,769,1,0,7,56,116,56,121,30,52,-65,-11,-77,-13,120
Наверное юзать более свежие версии андроида.
В октябре прошлого года это поправили:
Судя по тегам это исправление попало в релиз начиная с версии 7.1.1
Это к сожалению во многих случаях (в большинстве ?) невозможно.
Функция сия находится в библиотеке libandroid_servers.so
readelf -Ws /system/lib64/libandroid_servers.so | c++filt | grep Setter
416: 0000000000021f38 164 FUNC GLOBAL DEFAULT 12 void android::JavaObject::callSetter<unsigned char>(char const*, unsigned char*, unsigned long)
Ее конечно можно и для 7.0.0 попытаться пересобрать с патчем, или же пытаться пропатчить сам бинарник.
В любом случае надо еще разблокировать ‘readonly’ для /system (методы предлагаемые на xda-developers.com у меня не работают)
/dev/block/dm-0 /system ext4 ro,seclabel,relatime,data=ordered 0 0
В октябре прошлого года это поправили:
+5
А финт, если либу положить в сборку APK и она загрузиться первой. А то и вовсе может быть возможно переназначить этот вызов на свой JavaObject::callSetterFix. По крайней мере при сборке на обычном С++ бывает ругается, что существуют две реализации и он выбирает какую-то одну.
Вообще андроид странный, я 4 месяца пытался собрать rtkgps+, чтобы он не падал на моём телефоне. И вот недавно я выяснил причину, что в java и в нативном коде массивы которые копировались друг в друга были разной длинный. Но на моём андроиде копирование молча падало в дебрях системы, на на более новых нет, и как бы работало О_о
Так же спасибо Sergey Astakhov, твои unix сокеты пригодились.
П.С. Так же я узнал секрет, как на андроиде записывать логи с приёмника с timetag-ом, что бы потом их можно было повторять в rtknavi - надо в конце имени файла добавить ::T
Наверное юзать более свежие версии андроида.
…
Судя по тегам это исправление попало в релиз начиная с версии 7.1.1
Единственный телефон с BCM4774 (AFAIK http://www.myfixguide.com/manual/huawei-honor-8-teardown ), для которого есть LineageOS 14.1 это Huawei Honor 8
https://forum.xda-developers.com/showpost.php?p=71279818
В нем “GPS fixed” (whatever that means) и Galileo официально не поддерживается (хотя само железо умеет ).
Для Mate 9 есть самопальный ROM https://forum.xda-developers.com/mate-9/development/shield-rom-mate-9-t3560304 и для него пишуть
Bugs:
- GPS doens't work if you aren't on B156 base
B156 я устанавливать не хочу, т.к. в нем пофиксили Vulnerability ID: HWPSIRT-2017-01060
http://www.huawei.com/en/psirt/security-advisories/2017/huawei-sa-20170306-01-smartphone-en
которую я естественно фиксить не хочу
Я дизассемблировал libandroid_servers.so из него (objdump отсюда https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-linux-gnu , IDApro для arm64 у меня нет, а demo для него не работает), и там конечно никакие кетайцы memory leak в navmessage
править и не думали.
При этом для Kirin960
- Huawei NOT RELEASING Kernel source code
Так что ситуация на данный момент довольно запутанная.
Если у кого есть телефон с 7.1.1 (и Qualcomm ?), то интересно узнать о вашем experience.
Я все-таки снес стандартную прошивку, и заменил ее на самопал
Теперь все read-write. GPS не работает по следующей причине
[ 16.240081s][pid:1,cpu4,init]init: (Parsing /init.connectivity.gps.rc took 0.00s.)
[ 18.029235s][pid:1,cpu7,init]init: Starting service 'gpsdaemon'...
[ 19.310211s][pid:1,cpu4,init]init: Service gpsd_4774 does not have a SELinux domain defined.
[ 19.696044s][pid:1,cpu6,init]init: Service 'gpsdaemon' (pid 459) exited with status 0
В /sepolicy gpsd_4774 действительно нет, в /property_contexts есть
ctl.gpsd_4774 u:object_r:gpsd_prop:s0
а добавить контекст в init.connectivity.gps.rc
service gpsd_4774 /vendor/bin/glgps4774 -c /data/gps/gpsconfig.xml
socket gps seqpacket 660 gps system
class late_start
user gps
group system inet sdcard_rw wakelock
disabled
не удается, так как при перезапуске он заменяется на версию из какого-то ramdisk.
При этом в ramdisk из boot.img такого файла нет (???)
В телефоне до хрена partitions, везде бекапы, резервные копии, логи.
Никакого ЦРУ не надо, китайцы какие только данные по дискам не распихали
Этот glgps4774 еще через AtCmdTransportPort=“/dev/appvcom9”
посылает телефону магические команды.
В SuplTlsCertPath=“/data/cust/xml/server.pem” никакого сертификата нет.
При этом есть запароленная пара
/vendor/etc/gnss/config/gnss_lss_slp_thirdparty.p12
и запароленный ключъ
/vendor/etc/gnss/config/gnss_lss_rfg_key_thirdparty.pem
Интересно кто и для чего ими пользуется. Пароль же тоже должен где-то
лежать.
cacert_location.pem и xtra_root_cert.pem отсутствуют.
Disk /dev/block/sda: 4 MB, 4194304 bytes, 8192 sectors
Disk /dev/block/sdb: 4 MB, 4194304 bytes, 8192 sectors
Disk /dev/block/sdc: 16384 sectors, 64.0M
Number Start (sector) End (sector) Size Name
1 128 255 512K frp
2 256 767 2048K persist
3 768 2047 5120K reserved1
Disk /dev/block/sdd: 124928000 sectors, 576M
Number Start (sector) End (sector) Size Name
1 128 255 512K vrl
2 256 383 512K vrl_backup
3 384 2559 8704K modem_secure
4 2560 4095 6144K nvme
5 4096 20479 64.0M oeminfo
6 20480 28671 32.0M secure_storage
7 28672 36863 32.0M modem_om
8 36864 37887 4096K modemnvm_factory
9 37888 38911 4096K modemnvm_backup
10 38912 41983 12.0M modemnvm_img
11 41984 43007 4096K modemnvm_system
12 43008 63487 80.0M splash2
13 63488 129023 256M cache
14 129024 129535 2048K bootfail_info
15 129536 130047 2048K misc
16 130048 138239 32.0M reserved2
17 138240 139263 4096K reserved10
18 139264 141311 8192K hisee_fs
19 141312 145407 16.0M dfx
20 145408 149503 16.0M rrecord
21 149504 149567 256K fw_lpm3_a
22 149568 150527 3840K reserved3_a
23 150528 151551 4096K hisee_img_a
24 151552 154623 12.0M fastboot_a
25 154624 155647 4096K vector_a
26 155648 156159 2048K isp_boot_a
27 156160 159743 14.0M isp_firmware_a
28 159744 162815 12.0M fw_hifi_a
29 162816 164863 8192K teeos_a
30 164864 181247 64.0M recovery2_a
31 181248 185343 16.0M sensorhub_a
32 185344 193535 32.0M boot_a
33 193536 209919 64.0M recovery_a
34 209920 214015 16.0M dts_a
35 214016 214527 2048K trustfirmware_a
36 214528 228863 56.0M modem_fw_a
37 228864 241663 50.0M reserved4_a
38 241664 262143 80.0M modemnvm_update_a
39 262144 270335 32.0M patch_a
40 270336 278527 32.0M version_a
41 278528 479231 784M vendor_a
42 479232 528383 192M product_a
43 528384 577535 192M cust_a
44 577536 1777663 4688M system_a
45 1777664 1810431 128M reserved5
46 1810432 15615999 52.6G userdata
Нашел, где находится используемый ramdisk.cpio.gz,
он в сборке .img на /dev/block/sdd32 с характерным названием boot_a
Также полностью пересобрал AOSP (7.0.0_r30) для generic_arm64 из исходников.
Коллеги, подскажите, есть ли смысл в приобретении китайского flight controller’a за $15 на neo-m8n типа https://www.aliexpress.com/item/F17533-Mini-M8N-GPS-Module-NEO-M8N-GPS-for-APM-2-6-2-8-PIX-PX4/32662584468.html
- blackbox на openlog для сбора треков на веле? Или там только координаты идут наружу и сырые данные не получить?
Сейчас пишу треки телефоном, для “разбора полётов”.
Смысл есть, даже если там стоит прошивка 3.х (а китаец заявляет Галлилео), где сырые данные прикрыты, то он на порядок лучше чем смартфон.
Смысл есть, даже если там стоит прошивка 3.х (а китаец заявляет Галлилео), где сырые данные прикрыты, то он на порядок лучше чем смартфон.
OK, тогда о чём спрашивать китайцев? О версии прошивки? (пусть ставят u-center и проверяют?
У подобных модулей есть версии для разных flight controller’ов (Pixhawk, cc3d, f3), но думаю там различия только в типах коннекторов и распиновке. Или я не прав? (китайцев перед заказом спрошу)
Какие ещё критерии выбора?
Версии не для контроллеров, а для самого чипа ublox.
Там ещё какие-то наё…ки с памятью бывают, что её так мало, что следующее обновление просто не влезет, хотя и нужды в нём пока особо нет.
Версии не для контроллеров, а для самого чипа ublox.
Там ещё какие-то наё…ки с памятью бывают, что её так мало, что следующее обновление просто не влезет, хотя и нужды в нём пока особо нет.
Под версиями для контроллеров я подразумевал разные варианты кабелей, не firmware, прошивка думаю одна, просто в одном варианте припаяно 6 проводов, а в другом 4, и коннекторы разные.
Ну и почитал про контрафакт, можно получить с ali или ebay M7 без флэша с наклейкой от M8…