Комментарии 4
Как то сомнительно что GNSS работает с точностью до метров в таком бюджетном решении.
Стоило ли прилагать усилия по уменьшению времени расчета , если сами показания GNSS скачут в пределах десятков метров?
Про ресурсы RAM микроконтроллера занятые этим алгоритмом ничего не сказано.
ChatGPT говорит, что на 2000 индексов надо будет 24 КБ RAM. Правда ли это, и сколько индексов реально у вас?
Если в городе с GNSS все в порядке (нет глушилок), то accuracy модуля составляет 2-3 метра. Причем, это просто модули общего назначения, не какие-то high precision
Не очень понимаю, о какой RAM вы говорите. Мы не храним индексы в оперативке, они лежат во флешке. Обход файла с H3-индексами происходит через последовательность операций f_lseek; f_read вычитывает лишь одну строку
Т.е. индексов гораздо больше чем 2000, если нельзя выделить даже 24 КБ RAM ?
Ну и понимаете же, что один трек не показатель. Может в это время на небе было видно 24 спутника. А такое счастье не всегда и везде.
В базовой зоне Москвы сейчас 21К индексов. Я не рассматривал перенос их в RAM, т.к. считывание с флеша работает в приемлемых таймингах и смысла переноса в более скоростную память нету.
Фундаментально вы правы, если есть проблемы с GNSS, задача on-the-enge поиска их никак не решит, как и server-side решение. Но в большей части устройства нормально ловят позицию и точно уж с разбросом не в десятки метров. Там, где работают глушилки - история отдельная
IoT Geofencing: как мы сократили время определения функциональных зон, используя H3-индексы