RTKlib/постпроцессинг

Navilock собирается “в ближайшее время” выпустить приемники серии NL-82022MP
http://www.navilock.com/produkte/N_62755/merkmale.html?setLanguage=en
на базе NEO-M8U (урезанный DeadReckoning без внешних данных wheeltick, но с акселерометром+гироскопом Bosch BMI160).
Доступа к сырым GPS данным и прошивке там конечно нет :sunglasses:

Вот нашел в китайских просторах доки по ubx-m8030.https://yadi.sk/d/zK7QM0oW3EeNhq

Неплохой вебинар про метод РРР.

Обнаружились исходники для 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

Наверное юзать более свежие версии андроида.
В октябре прошлого года это поправили:

https://android.googlesource.com/platform/frameworks/base/+/fe427f24e5788612bc271bfff1b07b36ecebf3af%5E%21/#F0

Судя по тегам это исправление попало в релиз начиная с версии 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

Единственный телефон с 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
которую я естественно фиксить не хочу :slight_smile:
Я дизассемблировал 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.

Я все-таки снес стандартную прошивку, и заменил ее на самопал :sunglasses:
Теперь все 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, везде бекапы, резервные копии, логи.
Никакого ЦРУ не надо, китайцы какие только данные по дискам не распихали :roll_eyes:
Этот 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 :roll_eyes:
Интересно кто и для чего ими пользуется. Пароль же тоже должен где-то
лежать.
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.х (а китаец заявляет Галлилео), где сырые данные прикрыты, то он на порядок лучше чем смартфон.

OK, тогда о чём спрашивать китайцев? О версии прошивки? (пусть ставят u-center и проверяют? :slight_smile:
У подобных модулей есть версии для разных flight controller’ов (Pixhawk, cc3d, f3), но думаю там различия только в типах коннекторов и распиновке. Или я не прав? (китайцев перед заказом спрошу)
Какие ещё критерии выбора?

Версии не для контроллеров, а для самого чипа ublox.
Там ещё какие-то наё…ки с памятью бывают, что её так мало, что следующее обновление просто не влезет, хотя и нужды в нём пока особо нет.

Под версиями для контроллеров я подразумевал разные варианты кабелей, не firmware, прошивка думаю одна, просто в одном варианте припаяно 6 проводов, а в другом 4, и коннекторы разные.

Ну и почитал про контрафакт, можно получить с ali или ebay M7 без флэша с наклейкой от M8…