Dane odebrane RS232C ,jak ustalić format danych?

Problem:
Chciałem pobrać dane z ciśnieniomierza (aparat medyczny)
do własnego programu .
Urządzenie posiada port RS232C ustawienia transmisji 9600,n,bit-8,stop-1.

Po dokonaniu pomiaru do portu wysyłane są dane - 9 ramek po 10 bajtów.
7 identycznych ramek zawiera dane (ramka rozpoczyna się bajtem FF) -
oznacza to że wszystkie ważne dane przesłane mogą być za pomocą jednej
10 bajtowej ramki .( sprawdzane , wyzerowanie innych i pozostawienie jednej
nienaruszonej daje prawidłowy odczyt po przesłaniu do programu dołączonego
do ciśnieniomierza ,wysłałem je po skrosowaniu COM1 i COM2 innym programem,
symulując obecność urządzenia ).
2 ramki zawierają jakieś nieistotne badziewie .

Dane z urządznia mogę odebrać , ale nie potrafię po mimo różnych
kombinacji ich zinterpretować aby ustalić jak są zapisane dane w tych 10
bajtach (Format ramki) .

Oryginalny program daje następujące odczyty po odebraniu danych z COM .

Dane, Ramka pierwsza ,przykładowy pomiar nr1:
Hex:
FF 67 28 0B 56 0D 48 21 0E 8D
Jako Dec:
255,103,40,11,86,13,72,33,14,141
Jako Bin:

11111111-01100111-00101000-00001011-01010110
00001101-01001000-00100001-00001110-10001101

Dane wyświetlone przez oryginalny program odbierający dane :

Edit-> Time: 06:45  
Edit-> Date: 1/8 
Edit-> SYS : 110  
Edit-> DIA :  39  
Edit-> H.R.:  91

Dane Zapisane do bazy Danych:

Date          Time      SYS_mmHg DIA_mmHg MAP_mmHg  Pulse_min
2008-01-08    06:45:00    110       39      63         91

Dane, Ramka pierwsza ,przykładowy pomiar nr2:
Jako Hex:
FF 7E 39 03 44 04 48 11 02 A4
Jako Dec:
255,126,57,3,68,4,72,17,2,164
Jako Bin:

11111111-01111110-00111001-00000011-01000100
00000100-01001000-00010001-00000010-10100100

Dane wyświetlone przez oryginalny program odbierający dane :

Edit-> Time: 04:20  
Edit-> Date: 1/9 
Edit-> SYS : 114  
Edit-> DIA :  62  
Edit-> H.R.:  67

Dane Zapisane do bazy Danych:

Date          Time      SYS_mmHg DIA_mmHg MAP_mmHg  Pulse_min
2008-01-09    04:20:00    114       62      79         67

Czy ktoś może wie jak to rozszyfrować ,spędziłem 2 dni nad próbą
interpretacji tych danych binarnych ,bez efektu ..
Prawdopodobnie w ramce zawarta jest CRC ,- zmiana jednego bitu w ramce
powoduje jej odrzucenie i brak odczytu .

Wolałbym pominąć debugowanie programu oryginału w celu podejrzenia jak
dane są przetwarzane bo jest to "rozdmuchana kiszka" napisana
w VB + parę .dll i .ocx ,syf na maksa...

Mógłbyś podać w jakich przedziałach mogą być wyniki(poszczególne wartości). Zarzuć jeszce ze 2 zestawy(też w ładnych tabelkach - albo i nawet w ładniejszych ;-) ). Zrób kilka testów, zapisz wyniki i jeżeli wyjdzie któryś parametr taki sam jak w innej próbie to zobacz, który jeszcze(oprócz 0) bajtu wygląda tak samo w obu ramkach. Informacje te są mi potrzebne do sprawdzenia mojej koncepcji(możliwe, że przesyłane jest tylko "odchylenie" od jakiejś wartości standardowej) :)

Do tego powinien byc opis protokolu. Jesli ten device ma komunikacje po rs to opis protokolu MUSI byc w manualu. Jesli go nie ma - pisac do producenta. Bez znajomosci protokolu rozszyfrowanie tego moze zajac nawet kilka lat [rotfl].

Podaję link do instrukcji obsługi urządzenia(paramerty mierzone):
http://download1.medion.de/downloads/anleitungen/bda2755de.pdf

Przykładowe pomiary i odczyt

ff 61 3a 0e 4c 0d 48 01 02 b4

255, 97, 58, 14, 76, 13, 72,  1,  2,180

11111111-01100001-00111010-00001110-01001100
00001101-01001000-00000001-00000010-10110100

                  odebrano:
Edit-> Time:  12: 13  
Edit-> Date:   1/ 10
Edit-> SYS :    98
Edit-> DIA :    49
Edit-> H.R.:    78

                  w bazie danych:
Date          Time    SYS_mmHg   DIA_mmHg   MAP_mmHg   Pulse
2008-01-10  12:13:00  98         49         65         78

ff 62 3a 0b 4c 0e 48 01 03 b4

255, 98, 58, 11, 76, 14, 72,  1,  3,180

11111111-01100010-00111010-00001011-01001100
00001110-01001000-00000001-00000011-10110100

                  odebrano:
Edit-> Time:  12: 14   
Edit-> Date:   1/ 10  
Edit-> SYS :    99  
Edit-> DIA :    50 
Edit-> H.R.:    75

                  w bazie danych:
Date          Time    SYS_mmHg   DIA_mmHg   MAP_mmHg   Pulse
2008-01-10  12:14:00  99         50         66         75

ff 5a 2a 05 4c 00 48 11 0b c8

255, 90, 42,  5, 76,  0, 72, 17, 11,200

11111111-01011010-00101010-00000101-01001100
00000000-01001000-00010001-00001011-11001000

                  odebrano:
Edit-> Time:  12: 16   
Edit-> Date:   1/ 10  
Edit-> SYS :    91
Edit-> DIA :    42
Edit-> H.R.:    69

                  w bazie danych:
Date          Time    SYS_mmHg   DIA_mmHg   MAP_mmHg   Pulse
2008-01-10  12:16:00  91         42         58         69

ff 6f 1a 02 5c 01 48 11 06 ba

255,111, 26,  2, 92,  1, 72, 17,  6,186

11111111-01101111-00011010-00000010-01011100
00000001-01001000-00010001-00000110-10111010

                  odebrano:
Edit-> Time:  12: 17   
Edit-> Date:   1/ 10
Edit-> SYS :    102
Edit-> DIA :    31
Edit-> H.R.:    82

                  w bazie danych:
Date          Time    SYS_mmHg   DIA_mmHg   MAP_mmHg   Pulse
2008-01-10  12:17:00  102        31         55         82

ff 5d 1a 0f 5c 03 48 11 0a b9

255, 93, 26, 15, 92,  3, 72, 17, 10,185

11111111-01011101-00011010-00001111-01011100
00000011-01001000-00010001-00001010-10111001

                  odebrano:
Edit-> Time:  12: 19  
Edit-> Date:   1/ 10
Edit-> SYS :    90
Edit-> DIA :    29
Edit-> H.R.:    95

                  w bazie danych:
Date          Time    SYS_mmHg   DIA_mmHg   MAP_mmHg   Pulse
2008-01-10  12:19:00  90         29         49         95

ff 6d 2a 00 5c 05 48 11 05 ab

255,109, 42,  0, 92,  5, 72, 17,  5,171

11111111-01101101-00101010-00000000-01011100
00000101-01001000-00010001-00000101-10101011

                  odebrano:
Edit-> Time:  12: 21   
Edit-> Date:   1/ 10
Edit-> SYS :    101
Edit-> DIA :    45
Edit-> H.R.:    80

                  w bazie danych:
Date          Time    SYS_mmHg   DIA_mmHg   MAP_mmHg   Pulse
2008-01-10  12:21:00  101        45         64         80

ff 73 3a 0b 4c 06 48 11 01 9d

255,115, 58, 11, 76,  6, 72, 17,  1,157

11111111-01110011-00111010-00001011-01001100
00000110-01001000-00010001-00000001-10011101

                  odebrano:
Edit-> Time:  12: 22   
Edit-> Date:   1/ 10
Edit-> SYS :    113
Edit-> DIA :    51 
Edit-> H.R.:    75

                  w bazie danych:
Date          Time    SYS_mmHg   DIA_mmHg   MAP_mmHg   Pulse
2008-01-10  12:22:00  113        51         72         75

Uwaga :kolejność w 'odebrano' i 'w bazie danych'
wynika z prezentacji graficznej w oryginalnym
programie odbierającym ramki i nie świadczy o tym że
w podobnej kolejności są przesyłane.

@Egonek:
Wiem że to nie puzzle dla 5-cio latka i nie rządam aby ktoś zmarnował sobie życie
na analizie tych danych , chodzi raczej o spojrzenie przez inną osobę co czasem pomaga
w rozwiązaniu problemu .Wiadomo,,, jak dane są uzyskane z jakiegoś powalonego algorytmu
lub zmiksowane dodatkowo ze stałymi znanymi tylko producentowi to kaplica ...

Po dłuższym wpatrywaniu się w te cyferki i zapisaniu 2 kartek rozkminek i tabelek, wymyśliłem.... gdzie i jak zapisywane są minuty.... Wiele to to nie jest ale zawsze coś(no i troche mniej danych do analizy zostaje ;-P ). Do rzeczy:
minuty= (górna połówka siódmego(licze od zera, pierwszy to ten, który ma zawsze wartość FF) bajtu) + piąty bajt(a dokładniej jego dolna połówka, ale że górna zawsze(chyba - tak przynajmniej wynika z danych, które przedstawiłeś), tak więc można przyjąć, że cały bajt). Czyli np(zestaw nr 1 z drugiego posta):

[...]
11111111-01100001-00111010-00001110-01001100
00001101-01001000-00000001-00000010-10110100
odebrano:
Edit-> Time: 12: 13
[...]
w bazie danych:
Date Time SYS_mmHg DIA_mmHg MAP_mmHg Pulse
2008-01-10 1200 98 49 65 78

no i ilość minut będzie równa pogrubiona wartość + podkreślona wartość czyli 0+13=13. A w drugim zestawie z pierwszego posta będzie 32+13=45. To powinno być dobrze.

//edit: Czwart bajt jest chyba (współ)odpowiezialny za puls...

//edit2:
Wymyśliłem :)
puls=(4ty & 11110000b) + 3ci;
Przykładzik:

[...]
11111111-01110011-00111010-00001011-01001100
00000110-01001000-00010001-00000001-10011101
w bazie danych:
Date Time SYS_mmHg DIA_mmHg MAP_mmHg Pulse
2008-01-10 1200 113 51 72 75

puls=(pogrubione & 240) + podkreślone; czyli 64+11=75. Reszta pewnie jest zapisywana w podobny sposób. Jakbyś sam nie dał rady to daj znać - jak znowu znajde chwile to to rozkminie.

P.S. Czy tylko ja mam wrażenie, że taki sposób zapisu mógł wymyślić tylko jakiś idiota? ;-)

@cyriel
Wielkie Dzięki za zainteresowanie :-) , sprawdzę i przeliczę to-to ,, napiszę jak poszło ...

Może coś takiego?

11111111-01100001-00111010-00001110-01001100
00001101-01001000-00000001-00000010-10110100

Edit-> SYS : 98 01100010
Edit-> DIA : 49 00110001
Edit-> H.R.: 78 01001110

11111111-01100001-00111010-00001110-01001100
00001101-01001000-00000001-00000010-10110100

Edit-> Time: 12: 13

dzejo napisał(a)

Podaję link do instrukcji obsługi urządzenia(paramerty mierzone):
http://download1.medion.de/downloads/anleitungen/bda2755de.pdf

To jest user manual a nie engineer manual.

dzejo napisał(a)

@Egonek:

Pan Egonek jak juz.

dzejo napisał(a)

Wiem że to nie puzzle dla 5-cio latka i nie rządam aby ktoś zmarnował sobie życie
na analizie tych danych , chodzi raczej o spojrzenie przez inną osobę co czasem pomaga
w rozwiązaniu problemu .Wiadomo,,, jak dane są uzyskane z jakiegoś powalonego algorytmu
lub zmiksowane dodatkowo ze stałymi znanymi tylko producentowi to kaplica ...

Wlasnie dlatego ten powalony algorytm jest opisany w engineer manual. Ciekawe jak sie tu liczy CRC. :>

Ciekawe jak sie tu liczy CRC.

Aha, powodzenia w ustalaniu tego - jezeli komus sie uda rozszyfrowac chociazby jaki wielomian i algorytm jest uzyty to chyle czola

Osobiscie jakos nie wierze w to, ze producent ujawnia specyfikacje protokolu

@ 0x666
Dzięki .
Właśnie tak samo mi wyszło ,,,mam jeszcze dzień tygodnia i miesiąc .
Napisałem część przetwarzającą ramkę i jest Ok!
Cyriel wpadł na właściwą metodę. [green]

SYS_mmHg 
11111111-[0110]0001-00111010-00001110-01001100
00001101-01001000-00000001-0000(0010)-10110100

DIA_mmHg
11111111-0110(0001)-[0011]1010-00001110-01001100
00001101-01001000-00000001-00000010-10110100

HR Pulse
11111111-01100001-00111010-0000(1110)-[0100]1100
00001101-01001000-00000001-00000010-10110100

Dzien tygodnia
11111111-01100001-0011(1010)-[0000]1110-01001100
00001101-01001000-00000001-00000010-10110100

Miesiąc
11111111-01100001-00111010-00001110-01001100
00001101-01001000-0000(0001)-[0000]0010-10110100

Godzina
11111111-01100001-00111010-00001110-0100(1100)
[0000]1101-01001000-00000001-00000010-10110100

Minuty
11111111-01100001-00111010-00001110-01001100
0000(1101)-01001000-[0000]0001-00000010-10110100

Nie rozpracowane :
11111111-01100001-00111010-00001110-01001100
00001101->01001000<-00000001-00000010-10110100

W nawiasach [] górna część bajtu tworzącego przesyłaną wartość
w nawiasach () wartość którą trzeba dodać do [ ]0000 .

Dzięki wszystkim,
Szczególne podziękowania dla cyriel i 0x666.

Ps . CRC chyba w tym nie ma ...
chociaż nie , to pewnie ostatni bajt , ale to już mało ważne ,weryfikacje ramek
można zrobić inaczej ( jest 7 identycznych w pakiecie)...
//EDIT

Suma kontrolna dla ramki 10 bitowej zawartej w tablicy 'buf' :

  unsigned char temp_Sys = 0 ;
   unsigned char temp_Dia = 0 ;
   unsigned char temp_Pulse = 0 ;
   unsigned char temp_Time_H = 0 ;  // godzina
   unsigned char temp_Time_Min = 0 ;// Minuta
   unsigned char temp_Date_D = 0 ; // dzien
   unsigned char temp_Date_W = 0 ; // miesiac
   unsigned char temp_Date_x = 0 ; // związek z datą tylko dla sumy
   unsigned int s_control = 0 ;
   unsigned int sum ;

   // SYS_mmHg
   temp_Sys = buf[1]& (unsigned char)0x0F0 ;   // H
   temp_Sys += ( buf[8]& (unsigned char)0x0F) ;// L

   // DIA_mmHg
   temp_Dia = buf[2]& (unsigned char)0x0F0 ;
   temp_Dia += ( buf[1]& (unsigned char)0x0F) ;

   // HR_mmHg Pulse
    temp_Pulse = buf[4]& (unsigned char)0x0F0 ;     //H
    temp_Pulse +=  ( buf[3]& (unsigned char)0x0F) ; //L

   // Time_H  Godziny
   temp_Time_H = buf[5]& (unsigned char)0x0F0 ; // H
   temp_Time_H += buf[4]& (unsigned char)0x0F ; // L

   // Time_Min Minuty
   temp_Time_Min = buf[7]& (unsigned char)0x0F0 ; // H
   temp_Time_Min +=  ( buf[5]& (unsigned char)0x0F) ; //L

  // Date_D ;  // dzien
   temp_Date_D = buf[3]& (unsigned char)0x0F0 ; // H
   temp_Date_D += buf[2]& (unsigned char)0x0F ; // L

  // Date_W ;  // Miesiac
   temp_Date_W = buf[7]& (unsigned char)0x0F ; // L

   temp_Date_x = buf[8]& (unsigned char)0x0F0 ; // H
   // Liczony tylko do sumy kontrolnej ,ma związek z datą

    s_control = temp_Sys+temp_Dia+temp_Pulse+temp_Time_H
                +temp_Time_Min +temp_Date_D+temp_Date_W + temp_Date_x  ;

    // ostatni bajt kontrolny w ramce == (unsigned char)sum
    sum = 0x000000FF&(441 - s_control) ;

othello napisał(a)

Osobiscie jakos nie wierze w to, ze producent ujawnia specyfikacje protokolu

Wydaje mi sie ze musi to udostepnic, inaczej nie dostanie CE czy jakos tak.

Ja nigdy nie rozumiałem takiego "na siłę utrudniania", to wkurwiające. Tak jak oglądałem plik Gw.dat od Guild Warsa, a tam w c*** sum CRC, okazało się że połowa jest nieużywana, a zajmują kilkanaście megabajtów.