Jeg ved ikke, hvilken gruppe dette spørgsmål skal være i, så fortæl mig venligst, hvor det eller skal anbringes!
Jeg har en vejrstation Meteoscan Pro 923 (samme som Nexus), hvor jeg gerne vil opsamle data fra de medfølgende sensorer via en modtager til 433 MHz og et Arduino-program. Det er lykkedes for så vidt, at jeg kan finde synk og vha. af kraftig skelen til koder fra https://rayshobby.net/wordpress/reverse-engineer-wireless-temperature-humidity-rain-sensors-part-1/ kan jeg dekode data, der er Manchesterkodet. Problemet er, at jeg ikke rigtig ved, hvor data starter.
Figur1 viser hele datapakken, der hver gang gentages ialt 3 gange. De blå kanal er selve data, den røde kanal er de tidspunkter, hvor data fanges. Derunder er der vist forskellige digitale kanaler fra Arduino-boardet: - D6 viser det vindue, indenfor hvilket der hentes data. - D7 er en triggerpuls - D8 er regeneret clock fra Manchesterkoden. Muligvis skal polariteten vendes om! - D10 er det samme som den røde kanal, altså hvor data samples. - D11, D12 og D13 viser synkroniseringen på hver enkelt af de brede startpulser. Figur2 og Figur3 er forstørrelser af henholdsvis starten og slutningen af pulstoget. Jeg har her valgt at lade datahentningen starte lige efter de tre brede pulser, men hvis der sendes hele bytes derefter, kommer der 4 bits i overskud i slutningen. Hvis synk består af en hel byte, er der stadig et bit i overskud. Er der nogen, som har erfaringer med lignende eller har gode ideer til hjælp! Først når jeg har styr på synk er det værd at forsøge at finde kodningen!
Har arbejdet lidt med Manchester kode (IBM 3270) i mine yngre dage, men kan ikke se dit billede på http://www.kg2.dk/Man/Manchester.htm - får en code 404...
MANCHESTER-kode er (bl.a) karakteriseret ved, at der er både DATA-info og KLOKKE / Takt -info i selve signalet. Normalt kommer DATA og så (millI-SEKUNDER (?)) senere kommer klokken/takten.
(Og så er der den "omvendte" - den INVERTEREDE også kaldet, men også her er formatet DATA og klokke/takt - den eneste forskel er at et '0' sendes som et '1' og omvendt .. )
Jeg ved ikke om du (udover disse billeder) ved noget om MANCH--koden ?
Men det betyder, at dersom du skal sende eks. 8 '0'-ller må der ske et fase-skift, således at korrekt fase (= 0 ) bliver klokket/taktet. Det er det du ser på fig 3 (bl.a). (og '1' ved den inverterede .. ).
Har du kode (micro-controlleren eller PC) som kan læse denne Manch-kode ? eller må den (de)-kodes manuelt.
Er der mønstre som går igen (eks. i 3270 protokollen starter hver transmission med en PRE-AMPLE, som giver besked til modtageren at nu er der data (og klokke) og ligeledes ved EOT (end of transmission ) ? Og er du sikker på at det er ASCII som udsendes ?
Har du en instruktions-manual på samme TFA Sinus - hvis ikke prøv at finde den på nettet ??? Og hvad er kommunikations-protokollen ??
Eller sagt lidt mere direkte - prøv at finde mere information på samme TFA- sinus ..
Evt. prøv at kontakte stedet/forhandleren, hvor du har købt den.
Kan du oplyse type - og præcsist navn på samme TFA Sinus , da vi (sikkert) er flere her i gruppen, som ønsker at hjælpe med dit problem.
Jeg har læst en del om Manchester kodningen og ved, hvordan den kan kodes og dekodes med IC-er. Jeg har lavet programmet i Arduino til dekodningen og får fint data ud, som svarer til de data, som PicoScope viser. På Arduinos serielle monitor får jeg følgende ud for figur1: Nr: 52. 35 8D 16 B2 77 FD 8B DA BD BF 00110101.10001101.00010110.10110010.01110111.11111101.10001011.11011010.10111101.10111111. hvilket jo passer med PicoScopes dekodning.
Jeg har overvejet at kontakte TFA, men de vil have, at man fortæller hvilket firma man er fra, og der kniber det. Desuden tror jeg ikke, at de frivilligt giver de oplysninger, det er jo en del af deres forretning. Manualen inderholder kun brugervejledning.
Jeg må gå i tænkeboks. Og jeg har lidt externe opgaver (nu hvor sneen er ved at forsvinde) så der KAN gå et par dage inden jeg svarer igen.
Men: Jeg har en ide om, at PREAMPLE kan samtidig være en identifikation af bit-strømmen (altså en indikation af HVEM (= TFA sinus)) som sender og at den sidste byte er en checksum (en LRC checksum / CRC8 (sandsynligvis LRC da chksum'men synes at være 8 bits) ). Det, som er imellem preample oc chksum er data , men er det temperatur, barometertryk, luftfugtighed og/eller ???? . Hvis dette er rigtigt mangler "bare" (!) at fortolke disse data. (suk!!)
Har du en ide om hvor ofte denne opdatering sker.....
EOT kan være forskellig fra fabrikant til fabrikant. Men jeg tror at i dette tilfælde er Chksum = EOT .
KR
PS: Kan du sende mig f.eks 10 forskellige bit-strømme, så kan jeg se på LRC/CRC 8 checksummen - ved lejlighed (om e par dage (1))...
Umiddelbar ville jeg sende forskellige temperaturer ind i "kassen" og se hvordan resultaterne (bit mønstrene) ændrer sig i forhold til de tidligere udsendte (med kendte temperaturer).
OK med en tænkepause, jeg har selv tænkt meget omkring dette! Der er flere sensorer til vejrstationen: 2 externe temperatur/fugtighed med ca. 47 sekunders interval (max 5 stk) 1 regnmåler med ca. 3 minutters interval 1 vindmåler/temperatur ca. 33 sek. interval Desuden har der været en UV-måler, den den har jeg ikke tilsluttet. Datapakken fra regnmåleren ser ud til at være kortere end de andre.
Den modtager, som jeg i øjeblikket bruger, er ikke særlig følsom, så du får kun data fra de to externe termometre/hydrometre.
Du får data senere, skal det være her eller direkte til dig via e-mail?
Jeg må vist hellere forklare lidt (efter at have tænkt lit over en bemærkning i sidste indlæg:)
I vores have har (læs: HAVDE) vi et drivhus, som kollapsede under de massive snemængder sidste vinter, så vi har et drivhus-ruin i haven. I sidste uge lykkedes det endelig konen at få fat i relevante oplysninger om hvor vi skaffer de rigtige (!) reservedele til samme drivhus, og nu er det så min opgave at få dette drivhus op igen. Og det var det jeg mente med eksterne opgaver (omend det eksterne er i egen have). Og det betyder, at jeg det meste af den lyse tid vil være i haven (reparerer det ******** (læs: fandens ) drivhus), hvis vejret tillader det. (Samtidig vil jeg tænke lidt over opgaven! - det var det jeg mente med tænkeboksen !)
Hverken GOOGLE eller YAHOO tillader at jeg/du sender eksekverbare filer (med mindre vi "snyder" og laver dem om til JPEG bil'der) , så jeg kan kopiere (CTL-C) og lægge dem ind i min LRC-checker. (Et delphi 7 program skrevet til formålet). Og hvornår du gør det er din afgørelse . Men må jeg foreslå til FREDAG. (Jeg hat lidt tid søndag.)
Jeg har selv et projekt med fliselægning, så det gør ikke mig så meget, at der går nogen tid. Det med at gemme data i billedfiler kender jeg ikke noget til, med mindre man da bare laver om på 'efternavnet'. Jeg lægger dem her, så kan det være, at andre også får lyst til at løse opgaven.
Det bliver ikke nemt, det her. Der er i virkeligheden tre forskellige sæt data i hver sending fra termometeret. Der var flere pakker, men ved samme temperatur og fugtighed var de ens.
Fugtigheden er sandsynligvis i en enkelt byte, medens temperaturen måske er i decimaltal. Og måske som syv bit med paritetsbit.
Data er for Kanal1 termometeret efter synk. Der mangler altså næsten en byte i starten. Første linje er temperatur og fugtighed aflæst på termometret. Anden linje er hex og binære værdier.
Det ovenstående er ret uoverskueligt, så jeg har sorteret efter stigende temperatur og fugtighed, og fjernet de tre første byte, der altid var det samme. Det ser ud til, at polariteten af 0 og 1 skal byttes.
Har arbejdet med dine data. Foreløbig ingen umiddelbar løsning, men jeg synes jeg kan kan se et vist mønster i data. Har skrevet et system som sorterer disse data og det er ud fra dette skema jeg (SYNES) jeg kan se dette mønster. Jeg har en fornemmelse af at koden 0x2a (som synes at gå igen i alle data) er skilletegnet mellem de 2 målingsdata. Men hvordan de hhv. 3 data og efterflg. 2 data skal fortolkes - er endnu uklart.
spekulerer osse lidt på, om det er 2 bytes pr data eller ??????
Men nåj jeg arbejder i haven (graver, roder, potter, planter etc.) tænker jeg (i baghovedet) på hvor disse data kan/skal dekodes. (PS: du sku ha set de såkaldte "lige" rækker når jeg tænker (hehe... ) jeg mener de ULIGE r,,,, ) -- De er rettet op nu !
Kan være floating point arith, omend i et noget specielt format.
Begynder at checke bit mønstre . Selv om det ikke er defineret i den oprindelige MANCH code kan det tænkes (??) om der er synch-bits inde i selve data. Hvis ja er det "bare" af "afbit(t)e" disse bits. Men det hører du mere om.
Jeg synes det er morsomt at "detektivere" (ordet opfundet til formålet) sådanne opgaver. Da jeg var aktiv i erhvervslivet, var det mange gange min opgave at løse denne form for tekniske opgaver. Så dette er "bare" en fortsættelse.
Når men ser bitmønstret, kan det så være andet end Manchester codet? Jeg har prøvet at invertere bitmønstret og derefter lagt data ind i Word. her har jeg så søgt med bitmønstret for f.eks 22, 24 og flere andre. Jeg formoder ikke, at man vil bruge mere dataplads end nødvendigt. Da der er flere målinger med samme fugtighed, skulle der jo være samme mønster ved samme fugt. Det har heller ikke givet mening, men det er jo ikke sikkert, at det blot er et enkelt byte, måske er de decimalt, men der burde alligevel være redundans. Fra mit arbejde 'arvede' jeg Delphi 5 prof. den har jeg også brugt meget til tekstbhandling og til GPS-tracking, Men i de senere år er det php, der optager mig (selv om de unge mennesker siger, at det er umoderne til hjemmesider - de kan nok ikke finde ud af det :-)). Siden fredag aften, hvor jeg lige nåede det sidste flisearbejde, har jeg ligget underdrejet med kraftig feber, men doktormanden vil ikke se min før mandag - han havde ikke flere testpinde.
Men denne opgave er langt sværere end nogen af de tidligere jeg har arbejdet med. Jweg har prøvet at lave binære analyser af de opgivne data /både på '1'-er og '0'-ler og det giver resultater, som ligger langt fra de decimale værdier.
Prøvet at ekskludere bit mønstre , sammenligne bit-mønstre, vende bits og vende bytes, men resultaterne er stadig langt fra de opgive decimal (24 grader etc.. ) .
Det (eneste ?? endnu ) jeg ikke har prøvet er om det er en form for bitmanipulering (i stil med Windows XP, W10 ) produktkoder , men den metode kræver lidt mere avanceret programmering. Og nu hvor have-sæsonen er kommet rigtig i gang må jeg lave arbejdet i weekenden og det afhænger også af om vi er ude eller har gæster.
Men jeg arbejder med sagen - selv om den repræsenterer visse udfordringer - for at sige det mildt....
heJ Fint om du kunne. Jo flere variable , jo bedre.
Men kan du lave dem således, at du holde den ene variabel konstant . eks. tempeartur og så varierer fugtigheden og derefter fugtighed konstant og variabel temperatur. Så er der noget at sammenligne.
Jeg brugte uge-enden (weekenden) til at tænke (og det er farligt- det giver ideer )) og det vil jeg prøve i løbet af nogen dage. Og melder tilbage.
Kan du bruge SNESTRUP2016@gmail.com i fremtiden. Jeg tror vi "misbruger" dette forum lidt med dette.
Omkring fredag - passer mig super .
Kr
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
