Уберите избыточные результаты. Форум читать стало невозможно. Оставте только инфу с 4 датчиков в бинарке и в десятичной системе (не более 8 результатов) или сверните их через вставку кода.
Дальше индификатор работоспособности 0 или 1 (1 - датчик не работает, 0 - работает)
3 последних - номер датчика 000 - нулевой, 001 - первый, 010 - второй, 011 - третий. Терерь если в DEC это перевести, получим цифры
1001011 11111111 0 0 ------ - 3 датчик, датчик не работает. 1001011 - 75, если бы датчик работал, было бы 1000011 - 67
------
1001001 11111111 0 0 ------ 1 датчик, датчик не работает 001001 - 73, если бы датчик работал, было бы 1000001 - 65
------
1001010 11111111 0 0 ------2 датчик, датчик не работает 1001010 - 74, если бы датчик работал, было бы 1000010 - 66
------
1000000 100100 0 0 ------ 0 датчик, датчик работает, растояние 100100 1000000 - 64, напишите, что бы было бы, если он не работал :)
1001000 100100 00 во так будет. Спасибо всем ребят. Если не сложно подскажите может ссылку на функции по зеркалированию двоичного кода кто встречал то? а то не нашел пока ниче.
Разобрался. Если кому надо выкладываю программу как пример с функциями разбивки данных, зеркалированию и перевода нужой части в десятичную систему.http://www.fayloobmennik.net/3765768
Ребята все еще не закончилось не знаю что с расстоянием делать начав делать подсчеты и тесты на ПО заметил что поторопился с выводами. Подскажите как может передоваться расстояние вот пример данных:
Второй и четвертый рассчет сходятся приблизительно а остальные не понятно почему 212 там где должно быть 40 см и почему 255 там где нет препятствии и 0 где в упор тогда.(
Ребята я разобрался с расстоянием но есть вопрос к вам. Есть проблема. Вот собственно показания с одного датчика А все рассписанно и переведенно:
Датчик А (00)
сантиметры
BIN
DEC
DEC(invert)
зеркально
20
1000000 0 0 0
0
1
0
30
1000000 11100 0 0
28
3
7
40
1000000 11100100 0 0
228
27
39
50
1000000 11110100 0 0
244
11
47
60
1000000 11100 0 0
28
3
7
70
1000000 10000010 0 0
130
125
65
80
1000000 1010 0 0
10
5
5
90
1000000 11101010 0 0
234
21
87
100
1000000 10000110 0 0
134
121
97
110
1000000 1010110 0 0
86
41
53
120
1000000 11001110 0 0
206
49
115
Из этой таблицы вы поймете что расстояние определятся спомощью зеркального чтения двоичного кода, но тут есть одно но белеберда отсюда и получается что Скетч наверное который мне дали при передачи двоичных данных которые начинаются на 0 эти нули отбрасывают поэтому в некоторых кодах символов не 8 как должно быть точнее как они должны приити а 6 или 5 или 7. эти нули при обычном переводе не имеют значения а вот если зеркально читать их то имеют большое значение. В таблице те строки в которых муть (я говорю про последний столбез зеркало) в этих строках заметьте меньше символом и если вручную подставить перед переводом недостающие нули то все сходиться=). Вопрос в чем заключается. Это скетч такой или сама МК Так шлет. Второй вариант мало вероятен на мои взгяд. А второи вопрос можно ли в ардуине предусмотреть например перед отправкой в Ком порт инверт данных? Помогите со скетчем хотя бы чтобы нули не воровал) Спасибо заранее.
Вот тот скетч который мне дали:
#include <TimerOne.h>
#define LEDPIN 13 // Вывод светодиода
#define BTNPIN 2
#define BUFFER_LENGTH 100
volatile uint16_t startImpuls;
volatile uint16_t lengthImpuls;
volatile uint16_t timerCount=0;
byte buffPos = 0;
byte Buffer[BUFFER_LENGTH];
byte packet[4];
byte posInPacket=0;
byte startBYTE = 15;
void setup()
{ /*
LOW — вызов прерывания всякий раз, когда на порту низкий уровень напряжения;
CHANGE – прерывание вызывается при изменении значения на входе;
RISING – вызов прерывания при изменении уровня напряжения с низкого (LOW) на высокое(HIGH)
FALLING – вызов прерывания при изменении уровня напряжения с высокого (HIGH) на низкое (LOW)
*/
startImpuls=0;
lengthImpuls=0;
pinMode(BTNPIN, INPUT);
for(int i=0; i< BUFFER_LENGTH; i++)
Buffer[i]=0;
Serial.begin(115200);
Timer1.initialize(20);
Timer1.attachInterrupt(callback); // attaches callback() as a timer overflow interrupt
attachInterrupt(0, fireUp, RISING);
}
void callback() { timerCount++; }
void loop()
{
if (lengthImpuls > 0)
{
uint16_t temp=0;
uint16_t li = lengthImpuls;
lengthImpuls=0;
//--------------------------//
// получена приамбула "1 1 1 1"
if (li >50 && li <60)
{
posInPacket =0;
}
// Расчитываю позицию массиве
temp = posInPacket / 8;
uint16_t bitPos = posInPacket;
// Разворачиваю позицию для метода bitSet(x,n)
bitPos = 7 - bitPos;
if (bitPos >= 8)
{
bitPos = posInPacket - (8*temp);
}
// Получен "0"
if (li >4 && li <6)
{
posInPacket ++;
}
// Получен "1"
else if (li >10 && li <15)
{
bitSet(packet[temp],bitPos);
posInPacket ++;
}
//digitalWrite(13,LOW);
// Отправить пакет "большему брату"
if (posInPacket > 15)
{
detachInterrupt(0);
// Serial.println("------");
for(int i=0; i<4; i++)
{
Serial.print(packet[i], BIN);
Serial.print(" ");
packet[i]=0;
}
Serial.println("");
posInPacket = 0;
attachInterrupt(0, fireUp, RISING);
}
//--------------------------//
}
}
// Функция обработки прерывания на подъем
void fireUp()
{
detachInterrupt(0);
startImpuls = timerCount;
attachInterrupt(0, fireDown, FALLING);
}
// Функция обработки прерывания на подъем
void fireDown()
{
detachInterrupt(0);
lengthImpuls = timerCount - startImpuls;
startImpuls=0;
timerCount=0;
attachInterrupt(0, fireUp, RISING);
}
Здесь утаканившиеся значения ? а то создается впечатления, что присутствуют ошибки счета.
А кто мешает вам переворачивать число в своем ПО ? Вы же говорили, что как угодно сможете в ПО крутить ? Предусматреть предварительную обработку можно. Только Вы расслабились :)
на 30, 60, 80, 110 - ошибки счета. (один - два, иногда 4 бита потерялась). Код не оптимальный.
Значения точные и ошибки счета НЕТ!. Я сделал как прочили. перепроверял несколько раз на каждои из значении. Во вторых я не говорил что не могу перевернуть. даже код на Делфи скинул программу читающий и преобразующий код в нужную фору. Но на компе читать анализировать где скольких нулей не хвататет и потом подставлять и только потом зеркалить и переводить довольно таки долго по времени. Вот поэтому вопрос, я в программирование ардуино не так силен поэтому и спрашиваю. Откидование лишних первых 0 описанно в скетче или это сам МК откидывает в парктронике? если в скетче как его переделать чтобы он не откидывал эти разряды? Человек у которого осцилографф есть пока никак не может со мной состыковаться( я бы уже давно выложил. я заинтересован в этом. но человек пока не может по работе ездит постоянно технику ремонтирует в больницах. вот и не могу его поимать. Поэтому если получится и будет необходимость то выложу хотя бы для других людей.
Да нет отзеркалировать я буду в ПО своем данная функция занимает мало времени и меня устраевает а вот проверять символы и доставлять нули дольше. Так все таки скетч убирает лишнии нули спереди. Замети скетч выводит только с единицы числа.
Код не оптимальный, и сделан, как говориться, в лоб. Но та как вам экономить место не надо, то он вполне подойдет.
Вы его проверяли?) Ну впринципе я все сделал все работает вот только есть еще маленький косяк. У меня почему то програ ловит помехи в коде(. Ну я так думаю я их отсею.) А код спасибо попробую.
Тоже интересно - как все заработает. У меня сдох дисплей на парктронике (8 шт), заменить не так просто - на новых другой протокол подключения (На старом жки индикатор, новые с лед, сигналы и количество проводов отличаются).
Тоже интересно - как все заработает. У меня сдох дисплей на парктронике (8 шт), заменить не так просто - на новых другой протокол подключения (На старом жки индикатор, новые с лед, сигналы и количество проводов отличаются).
Так что тебе конкретно надо сказать или помочь в чем?
Смотрим что на синхроимпульсе и дата. Желательно осцилографом или логическим анализатором. Можно самой ардуино. Потом смотрим по какому фронту синхроимпульса читается дата. Потом думаем в каком формате идут данные. Ничего сложного ))).
Да собственно другого то пути и нет - хотел не разбираться с протоколом обмена, а купить новый парктроник и заменить индикатор. Купил - на новом светодиодный индикатор, как в заголовке статьи, провода другие :(
Ладно, попробовал к контактам индикатора - решил что так будет проще. Ну дальше вы в вкурсе - динамическая индикация не сахар. на этом бросил эксперименты.
В итоге осталось только разбирать протокол обмена... Скоро 4 выходных - займусь (спасибо партии родной).
Модель Parkmaster 4-dj-06 (один из самых простых). 4 датчика
Логическим анализатором данные снял. Из того, что удалось выяснить "с наскока":
0. Основной блок передает информацию на дисплей через SPI-шину.
1. Полный пакет содержит 7 (!!!) посылок. Сначала 3 посылки с интервалом 50мс, потом 4 посылки с интервалом 25мс
2. Каждая посылка - 2 полных байта и один "полубайт" (или всего 5 нибблов)
3. Первый ниббл - номер посылки в пакете (обычное бинарное кодирование, младший бит - слева)
4. самый последний ниббл - всегда 0000
Теперь непонятки:
1. Почему 7 посылок (ну можно предположить, что 4 последние посылки в пакете - это информация с конкретного датчика, но это еще предстоит выяснить.. и зачем нужны предыдущие 3 посылки)?
2. Как дешифровать данные?
Ниже привожу код того, что успел выдрать при разных условиях работы:
165 пост почитай чуть выше и по аналогии переводи. у них у всех либо зеркально двоичный код или на прямую двоичный и все тут когда пачки переведешь в десятичный поиграешь с переводами в десятичную систему сразу начнет все прояснятся.
Гм. как-то странно отработала моя программа по считыванию кода.
почему-то считывается как
11100011010100100000
хотя я (глядя на осциллограмму) сказал бы, что это
11000110101001000000
Но суть от этого не меняется (выкинуть лишнюю единицу спереди и добавить один нуль сзади).
Результаты тестов получились вот такие:
Преграды нет.
Подключен только датчик А
10000011111111111000
11000011111111111000
10100011111111111000
11100011111111111000
10010011111111111000
11010011111111111000
10110011111111111000
Подключен только датчик B
10000011111111111000
10100011111111111000
11000011111111111000
11100011111111111000
10010011111111111000
11010011111111111000
10110011111111111000
Подключен только датчик C
10000011111111111000
10100011111111111000
11000011111111111000
11100011111111111000
10010011111111111000
11010011111111111000
10110011111111111000
Подключен только датчик D
10000011111111111000
11000011111111111000
10100011111111111000
11100011111111111000
10010011111111111000
11010011111111111000
10110011111111111000
Преграда на расстоянии 0,3м
Подключен только датчик А
10000011111111111000
11000011111111111000
10100011010100100000
11100011111111111000
10010011111111111000
11010011111111111000
10110011111111111000
Подключен только датчик B
10000011010100100000
10100011010100100000
11000011111111111000
11100011111111111000
10010011111111111000
11010011111111111000
10110011111111111000
Подключен только датчик C
10000011111111111000
10100011111111111000
11000011010100100000
11100011010100100000
10010011111111111000
11010011111111111000
10110011111111111000
Подключен только датчик D
10000011111111111000
11000011111111111000
10100011111111111000
11100011010100100000
10010011111111111000
11010011111111111000
10110011111111111000
P.S. 10 см не получается - после 0.3м система орет как потерпевшая и показывает на дисплее -P
Судя по всему, инфа идут парами для 2 датчиков. Пары A+B и C+D. .... получается что на дисплей идет не растояние, а некие результаты вычитыний растояний между датчиками.
Для дальнейшего анализа надо следующие замеры (Используем 2 датчика из 4):
A - B
1) A - 30 см, В - 60 см
2) A - 60 см, В - 30 см
3) A - 60 см, В - 60 см
4) A - 30 см, В - 30 см
C - D
1) С - 30 см, В - 60 см
2) С - 60 см, В - 30 см
3) С - 60 см, В - 60 см
4) С - 30 см, В - 30 см
Для датчика A - 4-5 измерений с дельтой растояния 10- 15 см.
Вроде как при подключении всех датчиков, у вас должно быть 8 посылок...
Неправильно считывание программой идет потому, что вы считываете значение DATA по спаду импульса CLK, а надо по фронту.
Варианты с 0,3-0,6 (и наоборот) для каждой пары пока не снял - чуть позже сделаю.
Пока дополнительно обнаружилось, что если датчик подключен всего один - то на дисплее отображаются расстояния от 0.3 до 0.9м, все что больше - индицируется "прочерком".
Если же подключена пара датчиков (левая или правая) - то показываются расстояния до 1.5м
посмотрите на осцилографе, в какой момнт происходит изменение DATA относительно CLK (в том маштабе, в котором дана картинка это плохо видно, но мне кажется при наростании...).
Если при наростании, то считывание проходит по спаду, а значит значения которые получаются сечас, не совсем корректные. В текущий момент, возможно, это не так важно, но ИМХО надо сделать правильно...
"Неправильно считывание программой идет потому, что вы считываете значение DATA по спаду импульса CLK, а надо по фронту" - ошибся, надо данные читать по спаду. должно быть attachInterrupt(0, isr_DATA, FALLING);
ВЫ кода в первый раз писали, было правильно. Делайте все измерения в таком формате
сделате, по возможности вывод, в следующем формате (для анализа удобнее будет)
0000 0111 1111 1111 0000
мне кажется что (где 0 - 6 - это номер посылки)
0 - B
1 - C
2 - A
3 - D
4 - ??? пары В - С или A - D
5 - A-B или В-A
6 - C-D или D-С
0000 0111 1111 1111 0000 - 1 четыре цифры - номер посылки, 011 - величина постоянная, 1 1111 1111 - растояние, 0000 - величина постоянная
Могу ошибаться...
Кстати, у вас на дисплее случайно не 3 зоны, в которых отслеживается растояние ? (фото дисплейчика скиньте, если не сложно)
Недостающие данные завтра подготовлю - сегодня уже не успел :(
Дисплейчик простой:
Эпюры с осциллографа крупно:
По эпюрам видно, что вообще все равно, по фронту считывать или по спаду (что, кстати, подтверждает и скетч) - данные при FALLING ровно точно такие же. Почему спереди затесалась "1" и не хватает "0" на конце - буду разбираться позже: на значимые данные это не влияет.
За догадки по составу пакета - спасибо, очень похоже. Как только я подготовлю недостающие данные, думаю, картинка должна проясниться. Ну а там уже, надеюсь, будет понятно, как высчитать расстояние до преграды.
с вычислением растояний и флагом, что, есть данные похожи на правду (можно это флагом исправности датчика назвать :))
ИМХО Есть следующая гипотеза, учитывая "Сначала 3 посылки с интервалом 50мс, потом 4 посылки с интервалом 25мс" (проявиться при подключении всех датчиков) :
0 - растояние в середине, среднее между AC или AD (средняя зона)
6 и 7 символ номер датчика. Вот только не понятно почему он меняется при появлении препятствия?
Вот один датчик и препятствие перед ним в 40 см
1001001 11111111 0 0
С расстоянием разобрался надо зеркалить и все сходиться(. Вот только что делать с номером датчика от чего зависит как индифицировать его без ошибок.
1001000 100100 00 во так будет. Спасибо всем ребят. Если не сложно подскажите может ссылку на функции по зеркалированию двоичного кода кто встречал то? а то не нашел пока ниче.
зеркалированию двоичного кода - это вы что имеете ввиду ?
Ну у меня расстояние получается передается в двоичном коде но перевернуто оно
Разобрался. Если кому надо выкладываю программу как пример с функциями разбивки данных, зеркалированию и перевода нужой части в десятичную систему.http://www.fayloobmennik.net/3765768
Когда сделаю под прогу покажу весь кодинг и результат еще раз спасибо всем.
Ребята все еще не закончилось не знаю что с расстоянием делать начав делать подсчеты и тесты на ПО заметил что поторопился с выводами. Подскажите как может передоваться расстояние вот пример данных:
11010100 = 27*1 + 26*1 + 25*0 + 24*1 + 23*0 + 22*1 + 21*0 + 20*0 = 128 + 64 + 0 + 16 + 0 + 4 + 0 + 0 = 212
1011100 = 26*1 + 25*0 + 24*1 + 23*1 + 22*1 + 21*0 + 20*0 = 64 + 0 + 16 + 8 + 4 + 0 + 0 = 92
11111111 = 27*1 + 26*1 + 25*1 + 24*1 + 23*1 + 22*1 + 21*1 + 20*1 = 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = 255
а вот с дистанцией в 60 см примерно:
1000001 = 26*1 + 25*0 + 24*0 + 23*0 + 22*0 + 21*0 + 20*1 = 64 + 0 + 0 + 0 + 0 + 0 + 1 = 65
Второй и четвертый рассчет сходятся приблизительно а остальные не понятно почему 212 там где должно быть 40 см и почему 255 там где нет препятствии и 0 где в упор тогда.(
сделать несколько замеров с 1 датчиком с изменяющимся растоянием от 2 до 0.1 м с интервалом 10 - 20 см
выделить строку подключенного датчика в замерах
убрать повторяющиеся значения
посмотреть внимательно. ну можно сюда выложить. Только не сырые данные !!! а уже обработанные как указано выше
желательно для bin и dec это сделать
Если датчик не подключен он всегда будет показывать 11111111 (255)
Сделаю
XsanderS как у вас дела с парктроником? Что в вашем случае как протокол выглядит точно? и как шифруется расстояние?
Ребята я разобрался с расстоянием но есть вопрос к вам. Есть проблема. Вот собственно показания с одного датчика А все рассписанно и переведенно:
Из этой таблицы вы поймете что расстояние определятся спомощью зеркального чтения двоичного кода, но тут есть одно но белеберда отсюда и получается что Скетч наверное который мне дали при передачи двоичных данных которые начинаются на 0 эти нули отбрасывают поэтому в некоторых кодах символов не 8 как должно быть точнее как они должны приити а 6 или 5 или 7. эти нули при обычном переводе не имеют значения а вот если зеркально читать их то имеют большое значение. В таблице те строки в которых муть (я говорю про последний столбез зеркало) в этих строках заметьте меньше символом и если вручную подставить перед переводом недостающие нули то все сходиться=). Вопрос в чем заключается. Это скетч такой или сама МК Так шлет. Второй вариант мало вероятен на мои взгяд. А второи вопрос можно ли в ардуине предусмотреть например перед отправкой в Ком порт инверт данных? Помогите со скетчем хотя бы чтобы нули не воровал) Спасибо заранее.
Вот тот скетч который мне дали:
#include <TimerOne.h> #define LEDPIN 13 // Вывод светодиода #define BTNPIN 2 #define BUFFER_LENGTH 100 volatile uint16_t startImpuls; volatile uint16_t lengthImpuls; volatile uint16_t timerCount=0; byte buffPos = 0; byte Buffer[BUFFER_LENGTH]; byte packet[4]; byte posInPacket=0; byte startBYTE = 15; void setup() { /* LOW — вызов прерывания всякий раз, когда на порту низкий уровень напряжения; CHANGE – прерывание вызывается при изменении значения на входе; RISING – вызов прерывания при изменении уровня напряжения с низкого (LOW) на высокое(HIGH) FALLING – вызов прерывания при изменении уровня напряжения с высокого (HIGH) на низкое (LOW) */ startImpuls=0; lengthImpuls=0; pinMode(BTNPIN, INPUT); for(int i=0; i< BUFFER_LENGTH; i++) Buffer[i]=0; Serial.begin(115200); Timer1.initialize(20); Timer1.attachInterrupt(callback); // attaches callback() as a timer overflow interrupt attachInterrupt(0, fireUp, RISING); } void callback() { timerCount++; } void loop() { if (lengthImpuls > 0) { uint16_t temp=0; uint16_t li = lengthImpuls; lengthImpuls=0; //--------------------------// // получена приамбула "1 1 1 1" if (li >50 && li <60) { posInPacket =0; } // Расчитываю позицию массиве temp = posInPacket / 8; uint16_t bitPos = posInPacket; // Разворачиваю позицию для метода bitSet(x,n) bitPos = 7 - bitPos; if (bitPos >= 8) { bitPos = posInPacket - (8*temp); } // Получен "0" if (li >4 && li <6) { posInPacket ++; } // Получен "1" else if (li >10 && li <15) { bitSet(packet[temp],bitPos); posInPacket ++; } //digitalWrite(13,LOW); // Отправить пакет "большему брату" if (posInPacket > 15) { detachInterrupt(0); // Serial.println("------"); for(int i=0; i<4; i++) { Serial.print(packet[i], BIN); Serial.print(" "); packet[i]=0; } Serial.println(""); posInPacket = 0; attachInterrupt(0, fireUp, RISING); } //--------------------------// } } // Функция обработки прерывания на подъем void fireUp() { detachInterrupt(0); startImpuls = timerCount; attachInterrupt(0, fireDown, FALLING); } // Функция обработки прерывания на подъем void fireDown() { detachInterrupt(0); lengthImpuls = timerCount - startImpuls; startImpuls=0; timerCount=0; attachInterrupt(0, fireUp, RISING); }Здесь утаканившиеся значения ? а то создается впечатления, что присутствуют ошибки счета.
А кто мешает вам переворачивать число в своем ПО ? Вы же говорили, что как угодно сможете в ПО крутить ? Предусматреть предварительную обработку можно. Только Вы расслабились :)
на 30, 60, 80, 110 - ошибки счета. (один - два, иногда 4 бита потерялась). Код не оптимальный.
Где обещанный осцилограф ???
Значения точные и ошибки счета НЕТ!. Я сделал как прочили. перепроверял несколько раз на каждои из значении. Во вторых я не говорил что не могу перевернуть. даже код на Делфи скинул программу читающий и преобразующий код в нужную фору. Но на компе читать анализировать где скольких нулей не хвататет и потом подставлять и только потом зеркалить и переводить довольно таки долго по времени. Вот поэтому вопрос, я в программирование ардуино не так силен поэтому и спрашиваю. Откидование лишних первых 0 описанно в скетче или это сам МК откидывает в парктронике? если в скетче как его переделать чтобы он не откидывал эти разряды? Человек у которого осцилографф есть пока никак не может со мной состыковаться( я бы уже давно выложил. я заинтересован в этом. но человек пока не может по работе ездит постоянно технику ремонтирует в больницах. вот и не могу его поимать. Поэтому если получится и будет необходимость то выложу хотя бы для других людей.
поставте вместо этого
for(inti=0; i<4; i++){Serial.print(packet[i], BIN);090Serial.print(" ");091packet[i]=0;092}093Serial.println("");это
Serial.print(packet[0], BIN); Serial.print(" "); int dist; for (int i = 0; i < 8 ; ++i) { bitSet(((packet[0] >> i) & 1),7 - bitPos); } Serial.print(dist, BIN); packet[0]=0; packet[1]=0;С этим куском даже не компилиться)
Да, с код не рабочий. Ночью плохо пишется...
Идея следущая, найдите алгоритм и отзеркалируйте packet[1] и будет вам счастье
Да нет отзеркалировать я буду в ПО своем данная функция занимает мало времени и меня устраевает а вот проверять символы и доставлять нули дольше. Так все таки скетч убирает лишнии нули спереди. Замети скетч выводит только с единицы числа.
Вод фунция зеркалирования байта. Вставите в конце скетча
byte zerkal_byte(byte a) { return ( (((a >> 0) & 1) * 128) + (((a >> 1) & 1) * 64) + (((a >> 2) & 1) * 32) + (((a >> 3) & 1) * 16) + (((a >> 4) & 1) * 8) + (((a >> 5) & 1) * 4) + (((a >> 6) & 1) * 2) + (((a >> 7) & 1) * 1) ); }Это вывод. Заменить то что я писал раньше.
Serial.print(packet[0], BIN); Serial.print(" "); Serial.print(zerkal_byte(packet[0]), BIN); packet[0]=0; packet[1]=0;Код не оптимальный, и сделан, как говориться, в лоб. Но та как вам экономить место не надо, то он вполне подойдет.
Вод фунция зеркалирования байта. Вставите в конце скетча
byte zerkal_byte(byte a) { return ( (((a >> 0) & 1) * 128) + (((a >> 1) & 1) * 64) + (((a >> 2) & 1) * 32) + (((a >> 3) & 1) * 16) + (((a >> 4) & 1) * 8) + (((a >> 5) & 1) * 4) + (((a >> 6) & 1) * 2) + (((a >> 7) & 1) * 1) ); }Это вывод. Заменить то что я писал раньше.
Serial.print(packet[0], BIN); Serial.print(" "); Serial.print(zerkal_byte(packet[0]), BIN); packet[0]=0; packet[1]=0;Код не оптимальный, и сделан, как говориться, в лоб. Но та как вам экономить место не надо, то он вполне подойдет.
Вы его проверяли?) Ну впринципе я все сделал все работает вот только есть еще маленький косяк. У меня почему то програ ловит помехи в коде(. Ну я так думаю я их отсею.) А код спасибо попробую.
Serial.print(zerkal_byte(packet[1]) ОпечаткаТоже интересно - как все заработает. У меня сдох дисплей на парктронике (8 шт), заменить не так просто - на новых другой протокол подключения (На старом жки индикатор, новые с лед, сигналы и количество проводов отличаются).
Тоже интересно - как все заработает. У меня сдох дисплей на парктронике (8 шт), заменить не так просто - на новых другой протокол подключения (На старом жки индикатор, новые с лед, сигналы и количество проводов отличаются).
Так что тебе конкретно надо сказать или помочь в чем?
Мой парктроник 5 проводной (- ,+, синхроимпульс, дата, звук). Индикатор ЖК, собственно от него ножки поотвалились - вот и не работает, пищит только...
Смотрим что на синхроимпульсе и дата. Желательно осцилографом или логическим анализатором. Можно самой ардуино. Потом смотрим по какому фронту синхроимпульса читается дата. Потом думаем в каком формате идут данные. Ничего сложного ))).
Да собственно другого то пути и нет - хотел не разбираться с протоколом обмена, а купить новый парктроник и заменить индикатор. Купил - на новом светодиодный индикатор, как в заголовке статьи, провода другие :(
Ладно, попробовал к контактам индикатора - решил что так будет проще. Ну дальше вы в вкурсе - динамическая индикация не сахар. на этом бросил эксперименты.
В итоге осталось только разбирать протокол обмена... Скоро 4 выходных - займусь (спасибо партии родной).
Seltvik, ну как удалось расшифровать данные с датчика? А то как раз решил скрестить ардуину и датчик от парктоника
Вот и я добрался до парктроника...
Модель Parkmaster 4-dj-06 (один из самых простых). 4 датчика
Логическим анализатором данные снял. Из того, что удалось выяснить "с наскока":
0. Основной блок передает информацию на дисплей через SPI-шину.
1. Полный пакет содержит 7 (!!!) посылок. Сначала 3 посылки с интервалом 50мс, потом 4 посылки с интервалом 25мс
2. Каждая посылка - 2 полных байта и один "полубайт" (или всего 5 нибблов)
3. Первый ниббл - номер посылки в пакете (обычное бинарное кодирование, младший бит - слева)
4. самый последний ниббл - всегда 0000
Теперь непонятки:
1. Почему 7 посылок (ну можно предположить, что 4 последние посылки в пакете - это информация с конкретного датчика, но это еще предстоит выяснить.. и зачем нужны предыдущие 3 посылки)?
2. Как дешифровать данные?
Ниже привожу код того, что успел выдрать при разных условиях работы:
После тройного дефиса - дешифрованные нибблы
Есть идеи, как дешифровать?
P.S. еще сниму полный пакет данных при каком-нибудь отключенном датчике - видимо, где-то еще бит "исправности" должен быть
Вы всю мою тему прочитали? Ищите я там писал как кодируется обычно сигнал.
Да, всю тему прочитал, конечно.. но пока не понимаю, как это к моему конкретному случаю относится (кроме того, что это тоже парктроник).
В моем сигнал несколько хитрее - зачем-то 7 посылок в цикле (хотя датчиков всего 4)
и не могу пока понять закономерность - в какой части посылки искать расстояние (и как декодировать его).
Посылки у меня "пронумерованы" - откинуть какие-то определенные не составляет труда. Нужно бы понять, как расстояние декодировать?
165 пост почитай чуть выше и по аналогии переводи. у них у всех либо зеркально двоичный код или на прямую двоичный и все тут когда пачки переведешь в десятичный поиграешь с переводами в десятичную систему сразу начнет все прояснятся.
По очереди подключите 1 датчик к каждому входу. Снимите посылки для каждого случая. Перед датчиками ничего не ставте (должны смотреть вдаль...).
Аналогично с припятствием в 10 см пред каждым датчиком.
Итого 8 измерений
roman2712@ma, ок, методику понял - сделаю.
Пока нет доступа "до тела" - написал небольшую прогу для ардуино - которая будет снимать код со SPI-шины (пока не проверял).
Чтобы не потерялось - привожу код тут:
// логер данных с парктроника /* подключение: ардуино - парктроник D2 - SCK D3 - CS D4 - DATA */ boolean buffer[21]; // посылка - 8+8+4 бита volatile boolean waitCS = false; volatile int tact = 0; void setup() { pinMode(2, INPUT); pinMode(3, INPUT); pinMode(4, INPUT); if (digitalRead(3) == LOW) { waitCS = true; } attachInterrupt(1, isr_CS, CHANGE); Serial.begin(115200); } void loop() { // если "отпустили" CS // и счетчик тактов не равен нулю (т.е. посылку считали) if ((waitCS == false) && (tact != 0)) { for(int i=0; i<20; i++){ Serial.print(buffer[i]); } Serial.println(); // обнулим счетчик тактов tact=0; } } void isr_CS(){ // когда CS прижат к земле - включаем обработчик прерываний на D2 if (waitCS == true) { // взведем прерывание 0 attachInterrupt(0, isr_DATA, RISING); } else { // уберем обработчик прерывания 0 detachInterrupt(0); } // инвертируем значение флага waitCS =! waitCS; } void isr_DATA(){ buffer[tact]=digitalRead(4); tact++; }Код компилируется, в железе проверю вечером (заодно и сразу "срисую" посылки для требуемых случаев)
P.S. подключение напрямую ко входам ардуины - поскольку я уже заранее проверил, что там TTL-уровни на шине.
я вот не пойму. 8+8+4 бита = 22
тогда массив должен быть
а цикл например
for(int i=0; i<22; i++){ Serial.print(buffer[i]); }8+8+4 = 20
В обьявлении массива ошибка (можно было 20 вместо 21 написать. В самой проге верно (
for(inti=0; i<20; i++)) :) )блин затупил))) 3 числа сложил
Гм. как-то странно отработала моя программа по считыванию кода.
почему-то считывается как
11100011010100100000
хотя я (глядя на осциллограмму) сказал бы, что это
11000110101001000000
Но суть от этого не меняется (выкинуть лишнюю единицу спереди и добавить один нуль сзади).
Результаты тестов получились вот такие:
P.S. 10 см не получается - после 0.3м система орет как потерпевшая и показывает на дисплее -P
Судя по всему, инфа идут парами для 2 датчиков. Пары A+B и C+D. .... получается что на дисплей идет не растояние, а некие результаты вычитыний растояний между датчиками.
Для дальнейшего анализа надо следующие замеры (Используем 2 датчика из 4):
A - B
1) A - 30 см, В - 60 см
2) A - 60 см, В - 30 см
3) A - 60 см, В - 60 см
4) A - 30 см, В - 30 см
C - D
1) С - 30 см, В - 60 см
2) С - 60 см, В - 30 см
3) С - 60 см, В - 60 см
4) С - 30 см, В - 30 см
Для датчика A - 4-5 измерений с дельтой растояния 10- 15 см.
Вроде как при подключении всех датчиков, у вас должно быть 8 посылок...
Неправильно считывание программой идет потому, что вы считываете значение DATA по спаду импульса CLK, а надо по фронту.
Вроде как при подключении всех датчиков, у вас должно быть 8 посылок...
В том-то и дело, что посылок 7 - ниже больший кусок лога.
Неправильно считывание программой идет потому, что вы считываете значение DATA по спаду импульса CLK, а надо по фронту.
Прерывание настроено именно на "по нарастанию":
поэтому и странно, что так считывается
Новые данные.
Только датчик А - разные расстояния
Пары датчиков A-B и C-D расстояния 0,3 и 0,6 (одинаковые)
Варианты с 0,3-0,6 (и наоборот) для каждой пары пока не снял - чуть позже сделаю.
Пока дополнительно обнаружилось, что если датчик подключен всего один - то на дисплее отображаются расстояния от 0.3 до 0.9м, все что больше - индицируется "прочерком".
Если же подключена пара датчиков (левая или правая) - то показываются расстояния до 1.5м
посмотрите на осцилографе, в какой момнт происходит изменение DATA относительно CLK (в том маштабе, в котором дана картинка это плохо видно, но мне кажется при наростании...).
Если при наростании, то считывание проходит по спаду, а значит значения которые получаются сечас, не совсем корректные. В текущий момент, возможно, это не так важно, но ИМХО надо сделать правильно...
"Неправильно считывание программой идет потому, что вы считываете значение DATA по спаду импульса CLK, а надо по фронту" - ошибся, надо данные читать по спаду. должно быть attachInterrupt(0, isr_DATA, FALLING);
ВЫ кода в первый раз писали, было правильно. Делайте все измерения в таком формате
сделате, по возможности вывод, в следующем формате (для анализа удобнее будет)
0000 0111 1111 1111 0000
мне кажется что (где 0 - 6 - это номер посылки)
0 - B
1 - C
2 - A
3 - D
4 - ??? пары В - С или A - D
5 - A-B или В-A
6 - C-D или D-С
0000 0111 1111 1111 0000 - 1 четыре цифры - номер посылки, 011 - величина постоянная, 1 1111 1111 - растояние, 0000 - величина постоянная
Могу ошибаться...
Кстати, у вас на дисплее случайно не 3 зоны, в которых отслеживается растояние ? (фото дисплейчика скиньте, если не сложно)
Недостающие данные завтра подготовлю - сегодня уже не успел :(
Дисплейчик простой:
Эпюры с осциллографа крупно:
По эпюрам видно, что вообще все равно, по фронту считывать или по спаду (что, кстати, подтверждает и скетч) - данные при FALLING ровно точно такие же. Почему спереди затесалась "1" и не хватает "0" на конце - буду разбираться позже: на значимые данные это не влияет.
За догадки по составу пакета - спасибо, очень похоже. Как только я подготовлю недостающие данные, думаю, картинка должна проясниться. Ну а там уже, надеюсь, будет понятно, как высчитать расстояние до преграды.
Еще раз спасибо за помощь!
Во... поиграл с цифирками
похоже, структура пакета чуть иная (рассматриваем "правильный" пакет, в начале которого нет "лишней" единицы и в самом конце есть еще один нуль:
к примеру вот такая посылка:
01000110000101000000
расставлю пробелы, как считаю правильным:
0100 011 0 0001 0100 0000
Т.о.:
первая часть - номер посылки
вторая часть - постоянная (возможно, для систем с передними и задними датчиками - будет изменяться)
третья часть - флаг того, что данные есть (?)
четвертая и пятая - расстояние (младший байт слева). Расстояние в сантиметрах - в вышеприведенной последовательности - 40 см.
шестая часть - постоянная
Теперь становится еще интереснее (разглядываю данные пар датчиков AB и CD):
Пара AB (смотрю только на те посылки, где есть данные). Первый столбец - номер посылки, второй столбец - расстояние в см:
Расстояние 0.6м
0 - 69
2 - 68
5 - 67
Расстояние 0.3м
0 - 41
2 - 40
5 - 39
Очень интересно. 2 посылка - среднее значение между двумя другими (!!!)
Проверим гипотезу на паре CD
Расстояние 0.6м
1 - 68
3 - 69
6 - 67
Расстояние 0.3м
1 - 40
3 - 41
6 - 39
Ага, тут "среднее" - 1 посылка
таким образом, картина посылок получается следующая:
0 - датчик A (или B)
1 - среднее справа (CD)
2 - среднее слева (AB)
3 - датчик C (или D)
4 - пока не выяснено - нужно снять данные сразу с 4 датчиков, думаю, получится "общее среднее"
5 - датчик B (или A)
6 - датчик D (или C)
Что скажете? Похоже на правду?
Похоже на правду
с вычислением растояний и флагом, что, есть данные похожи на правду (можно это флагом исправности датчика назвать :))
ИМХО Есть следующая гипотеза, учитывая "Сначала 3 посылки с интервалом 50мс, потом 4 посылки с интервалом 25мс" (проявиться при подключении всех датчиков) :
0 - растояние в середине, среднее между AC или AD (средняя зона)
4 - датчик A
и чего не сделаешь после полуночи.. недостающие данные
Осталось сделать "последний шаг"...