Как стать автором
Обновить

IoT Geofencing: как мы сократили время определения функциональных зон, используя H3-индексы

Уровень сложностиСредний
Время на прочтение16 мин
Количество просмотров846
Всего голосов 10: ↑10 и ↓0+13
Комментарии4

Комментарии 4

Как то сомнительно что GNSS работает с точностью до метров в таком бюджетном решении.
Стоило ли прилагать усилия по уменьшению времени расчета , если сами показания GNSS скачут в пределах десятков метров?
Про ресурсы RAM микроконтроллера занятые этим алгоритмом ничего не сказано.
ChatGPT говорит, что на 2000 индексов надо будет 24 КБ RAM. Правда ли это, и сколько индексов реально у вас?

  1. Если в городе с GNSS все в порядке (нет глушилок), то accuracy модуля составляет 2-3 метра. Причем, это просто модули общего назначения, не какие-то high precision

  2. Не очень понимаю, о какой RAM вы говорите. Мы не храним индексы в оперативке, они лежат во флешке. Обход файла с H3-индексами происходит через последовательность операций f_lseek; f_read вычитывает лишь одну строку

Т.е. индексов гораздо больше чем 2000, если нельзя выделить даже 24 КБ RAM ?
Ну и понимаете же, что один трек не показатель. Может в это время на небе было видно 24 спутника. А такое счастье не всегда и везде.

  1. В базовой зоне Москвы сейчас 21К индексов. Я не рассматривал перенос их в RAM, т.к. считывание с флеша работает в приемлемых таймингах и смысла переноса в более скоростную память нету.

  2. Фундаментально вы правы, если есть проблемы с GNSS, задача on-the-enge поиска их никак не решит, как и server-side решение. Но в большей части устройства нормально ловят позицию и точно уж с разбросом не в десятки метров. Там, где работают глушилки - история отдельная

Зарегистрируйтесь на Хабре, чтобы оставить комментарий