Неверные данные при изменении частоты передачи
- Войдите на сайт для отправки комментариев
В скетче каждые N миллисекунд отправляются данные с датчика в приложени на android.
При изменении частоты передачи расстояния датчика эти значения в самом приложении отображаются по-разному. Так, например, с частотой в 10 мс данные приходят более правдоподобные, чем с частотой в 500 мс. Под более правдоподобными данными я подразумеваю верное расстояние, чередующееся с неверным.
Пример данных с частотой отправки 10 мс - 0, 0, 0, 0, 130, 131, 130, 0, 0, 0.
Нули - неверные данные - частный случай. Бывает, что приходят 1, 2, 3 ,4 и так далее.
500 мс - сплошные неверные данные.
В принципе, можно подобрать наиболее удачную частоту. Но я не понимаю, каким образом она влияет на отображение данных в приложении. Приложение на писано на C# в Xamarin.
К слову, в BluetoothTerminal данные приходят почти всегда реальные, независимо от частоты.
Если потребуется код скетча или приложения - пишите.
Слишком много текста и ненужных подробностей. Стоило просто описать вашу проблему так: "Я хочу одно, а получаю совсем другое." Один фиг, никаких ответов в обоих случаях вы бы не получили, но писать пришлось бы меньше.
Да нет, не потребуются. У меня данные расстояния приходят всегда правильные. Код с ошибками не нужен.
В том и дело, я ошибок не вижу.
В том и дело, я ошибок не вижу.
А почему тогда решили, что они есть?
В том и дело, я ошибок не вижу.
А почему тогда решили, что они есть?
Я перебрал возможные варианты. Возможно, не все. Я могу чего-то и не знать. Приём данных в приложении осуществлен аналогично проекту блютуз-чата, который находится в открытом доступе на сайте xamarin.
При частоте 500 мс приходят нули.
При частоте 250 мс приходят двойки.
При частоте 100 мс приходят тройки.
При частоте 50 мс приходят нули и верные значения. Помимо этого в зависимости от реального расстояния встречаются отличные от нуля значения: при расстоянии в 15 см это единицы, при 27 см это двойки.
При частоте 10 мс приходит много верных значений, иногда появляются нули и первые цифры этих значений, как при частоте 50 мс. НО: данные приходят очень уж медленно, буквально раз в секунду, иногда вообще прерывается иничего не приходит пару секунд.
А может ну его нафиг?
При частоте 500 мс приходят нули.
При частоте 250 мс приходят двойки.
При частоте 100 мс приходят тройки.
При частоте 50 мс приходят нули и верные значения. Помимо этого в зависимости от реального расстояния встречаются отличные от нуля значения: при расстоянии в 15 см это единицы, при 27 см это двойки.
При частоте 10 мс приходит много верных значений, иногда появляются нули и первые цифры этих значений, как при частоте 50 мс. НО: данные приходят очень уж медленно, буквально раз в секунду, иногда вообще прерывается иничего не приходит пару секунд.
1. Частота измеряется в Гц. В мс изеряется время. Напримеро, период.
2. Перечитайте выделенное мною и подумайте, как это вообще возможно.
При частоте 500 мс приходят нули.
При частоте 250 мс приходят двойки.
При частоте 100 мс приходят тройки.
При частоте 50 мс приходят нули и верные значения. Помимо этого в зависимости от реального расстояния встречаются отличные от нуля значения: при расстоянии в 15 см это единицы, при 27 см это двойки.
При частоте 10 мс приходит много верных значений, иногда появляются нули и первые цифры этих значений, как при частоте 50 мс. НО: данные приходят очень уж медленно, буквально раз в секунду, иногда вообще прерывается иничего не приходит пару секунд.
1. Частота измеряется в Гц. В мс изеряется время. Напримеро, период.
2. Перечитайте выделенное мною и подумайте, как это вообще возможно.
Я всё понимаю. Но я написал так, как оно есть на самом деле.
Так, как Вы написали, не может быть в принципе.
Потому что:
1. Частота измеряется в Гц. В мс измерять частоту нельзя.
2. 10 мс никак не могут быть 1 секундой.
Так, как Вы написали, не может быть в принципе.
Потому что:
1. Частота измеряется в Гц. В мс измерять частоту нельзя.
2. 10 мс никак не могут быть 1 секундой.
Код скетча:
periodcMessageFrequency - та самая переменная с мс, временной интервал между отправкой данных.
Особенно, конечно, впечатляют строки с 28 по 34.
Natt_Nei, если у Вас возникают какие-либо проблемы, в первую очередь следует их локализовать. Т.е. выяснить, то ли датчик выдает что-то невразумительно, то ли происходит потеря информации при передаче.
Увы, ни по коду, ни по Вашему описанию проблемы сделать какие-то выводы невозможно.
Особенно, конечно, впечатляют строки с 28 по 34.
Natt_Nei, если у Вас возникают какие-либо проблемы, в первую очередь следует их локализовать. Т.е. выяснить, то ли датчик выдает что-то невразумительно, то ли происходит потеря информации при передаче.
Увы, ни по коду, ни по Вашему описанию проблемы сделать какие-то выводы невозможно.
Выше писал. В bluetooth терминал данные приходят всегда реальные.