Svenska ElektronikForumet
https://elektronikforumet.com/forum/

Dekoda pulståg i Audacity
https://elektronikforumet.com/forum/viewtopic.php?f=10&t=88951
Sida 2 av 5

Författare:  lillahuset [ 21.14 2018-08-09 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

För några år sedan tipsade någon här på forumet (Mr Frenzy?) mig om GNU Radio. Det är ett väldigt kraftfullt verktyg för signalbehandling, om än lite knöligt att använda. Testa det, jag hade mycket nytta av det när jag försökte få en kund att berätta hur algoritmen för det de ville göra skulle se ut. Det är ingen dans på rosor men det brukar ju inte kraftfulla verktyg vara. Och det vi ville göra hade ingenting med radio att göra, bara signalbehandling.

Författare:  Magnus_K [ 21.19 2018-08-09 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

Mmmm intressant! Ska kika på det strax. Laddar just nu ner en mjukvara som kallas "Universal Radio Hacker". Tydligen väldigt omtyckt :)
Tror jag kan nyttja RTL-SDR för att hitta frekvensen och sen spela in/debugga signalen med den andra mjukvaran.

Författare:  Magnus_K [ 01.02 2018-08-18 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

Sitter och kikar på en signal, och först kommer det en puls som verkar vara en Preamble-signal.
Hur skulle ni tolka en period i den här signalen? Är en bit-längd som alt 1, 2 eller 3?

Bilaga:
Preamble.JPG

Författare:  kodar-holger [ 06.06 2018-08-18 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

Om det är preamble tror jag inte du säkert kan säga vilken det är. Du måste titta på data-portionen.

Författare:  Magnus_K [ 09.12 2018-08-18 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

Ja det ska väl vara preamble:n som sätter Baud-rate:n?

Ska göra ett inlägg i kväll om hur hela signalen ser ut. Sitter och försöker dekoda en väderstation på kvällarna men det går som väntat inte speciellt bra...

Författare:  Mickecarlsson [ 10.42 2018-08-18 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

Har du kollat på rtl_433?https://github.com/merbanan/rtl_433
Jag använder den mjukvaran för att loga min väderstation till Domoticz.
Chansen är att din väderstation redan finns i programmet.

Författare:  Magnus_K [ 10.52 2018-08-18 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

Tackar för tipset!
Den var inte med i device-listan men kan ju vara samma protokoll som andra prylar.

Hade bara varit kul att bli duktig på sånt här...

Författare:  xxargs [ 11.47 2018-08-18 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

du är ju på väg - att strula runt och prova olika metoder och aldrig ge upp är vägen för att bli duktig på 'det'

så är det för de flesta som folk upplever som duktiga - de ser resultatet men inte den långa 'träningen' bakom det.

Författare:  Magnus_K [ 13.15 2018-08-18 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

Ja, den här SDR-dongeln som jag blev tipsad om är fullkomligt fantastiskt. När man börjar lära sig kombon SDR Sharp ihop med Universal Radio Hacker så är man fast. :)
SDR sharp är dock lite överflödigt i mitt läge men spektrum analysatorn slår URH's med hästlängder tycker jag.

Ok. Kan göra ett försök att visa hur det ser ut.

Första bilden visar ett komplett meddelande från väderstationen till huvudenheten. Det verkar onekligen vara OOK-överföring vilket förenklar en del.
Den andra bilden visar vad jag antar är preamble + start av ett meddelande. Tiden mellan flankerna enligt översta alternativet i min tidigare bild är 450µs.
Gissar också att en preamble består av skiftande 1 och 0 enda chansen att få till det är att dubbla 450µs till 900µs enligt variant 2 i tidigare bild.
Vad tror ni om det?

Bilaga:
Burst.JPG

Bilaga:
Start_av_meddelande.JPG

Författare:  Castor [ 17.48 2018-08-18 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

Jag skulle gissa att första "bursten" synkar, sedan kommer en portion med alternerande 1:or och nollor, dvs bitlängden är som i ditt alternativ 3, läsning efter en tredjedel ger 1 eller 0.

Författare:  Magnus_K [ 17.53 2018-08-18 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

Tack för svaret Castor. En gissning är bättre än inget :)
Satt en stund och testade alt 2 innan men det "kändes inte rätt". Ska lägg lite mer tid på det du tror.

Författare:  Magnus_K [ 18.41 2018-08-18 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

Nu så! Nu blev det bättre! :D

Jag och ungarna satt och blåste på anemometern och sniffade signalen samtidigt. När den väl hade tagit några samples så kikade jag på huvudenheten vilken hastighet vi kom upp till, hela 4km/h.
Dock stämde detta MYCKET bra med bitarna 84-86. Som ni ser så säger det senaste samplet "4". Självklart är det fler än 3 bitar som representerar vindhastighet men jag ville bara markera något så ska jag rätta till etiketten senare när jag vet maxhastighet.

Gissar att det bara är att jobba vidare. Har löst vilka bitar som rapporterar vindriktning men inte ännu riktigt förstått hur.

Bilaga:
Debug.JPG

Författare:  peolah [ 19.12 2018-08-18 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

Det kanske är "Manchester Encoding" som används, vilket 90% av alla OOK/FSK2 baserade 433 MHz kortdistans-ISM gör.

Först kommer en antal preamblepulser + och sedan startbit/synk-bytes och eventuell adress + datapaketet + CRC (Polynombaserd - Olika för olika sändare). Om du har otur använder dom "whitening" vilket gör det lite svårare, men inte alls troligt med en väderstation.

Manchester kodning:
1-0 = 1
0-1 = 0

Sedan om du kan logga signalen, så är Saleae Logic analysator väldigt smidig, klarar både OOK/FSK - Manchester på ett kick.
Men det tar ju udden av utmaningen.. :)

Sedan tycker jag inte att Gnu Radio är knöligt, men det är väldigt långsamt i Windows. Det är viktigt med att man har en bra USB-drivrutin. Jag använder libusb-win32 som jag tycker fungerar bäst med Win7/10 på mina burkar. Men python-script direkt är överlägset stabilast eller köra Gnu Radio i linux.

Så här kan man exportera data från Saleae..

0.109220000000000,Manchester,0x93
0.121460000000000,Manchester,0xEF
0.133720000000000,Manchester,0x84
0.146010000000000,Manchester,0xB8
0.158230000000000,Manchester,0x06
0.170490000000000,Manchester,0x0F
0.182760000000000,Manchester,0xB4
0.195040000000000,Manchester,0x00

Författare:  Magnus_K [ 20.33 2018-08-18 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

Tack för all information peolah!
Nu är jag precis ny på det här men när jag ändrar till olika typer av Manchester-modulering (eller vad det heter på svenska) så förstår jag mig verkligen inte på datan alls. Dock jättebra att veta hur det ligger till för det lär jag testa först nästa gång!

Tack vare dig så löste jag precis sista pusselbiten också - CRC !
Trodde att det vara någon slags timestamp som väderstationen skickade med men efter du läst ditt inlägg så letade jag upp två exakt lika transmissioner, och visst, exakt samma 8 bitar på slutet.

Så här ser det ut nu:

Vindriktning, rapporterar 16 väderstreck, detta gör den med 4 bitar.
Vindstyrka, lite sammanträffande så är max styrka enligt manualen 256 km/h :wink:
Luftfuktighet, rapporterar direkt i %, går åt 7 bitar med misstänker 8 bitar är allokerade.
Ute-temp, rapporterar med (antagligen) 16 bitar. Då jag inte haft >25,5° när jag labbat så har jag inte sett fler bitar.
Regnmängd, ser att varje gång skålen tippar över i mätaren så adderas det 0,7mm/h på huvudenheten. När klockan går över varje hel timma så nollas den datan på displayen.
det jag dock inte blivit klok på än är när väderstationen nollar sin räknare, samt vad datan betyder.
Lufttryck verkar huvudenheten lösa själv tyvärr. Skulle gärna vilja haft det här också men det går ju alltid lösa med en egen sensor.

Så kvar att lösa är regnmängden, sen tror jag att det roliga kan börja på allvar!
Tack än en gång för all hjälp. Nu är jag mycket mindre beroende... :vissla:

Bilaga:
Debug.JPG

Författare:  Magnus_K [ 21.38 2018-08-18 ]
Inläggsrubrik:  Re: Dekoda pulståg i Audacity

Hmm, nej... blir inte klok på regnmängden.

Det står klart att regnmätaren består av en skopa som tippar över och tömmer när den blivit full. En sån tippning ökar en räknare med ett steg.
Denna räknare är minst 1 byte och nollställs (gissningsvis) först vid batteribyte.
Huvudenheten stämmer bara av vid början av varje timme vad mätaren rapporterar för värde på räknaren och sedan matchar värdena för varje gång mätaren rapporterar. Vid ny timme så uppdateras siffrorna i huvudenheten och den visar 0mm/h i igen.

Det konstiga är det här:

Kod: [Expandera/Minimera] [Hämta] (Untitled.txt)
  1. Räknarvärde                Visningsvärde i mm/h
  2. 00100100 (36)              0
  3. 00100101 (37)              0,7
  4. 00101001 (41)              3,9
  5. 00110010 (50)              11
  6.             Ny timma
  7. 00110010 (50)              0


Först tänkte jag att varje ökning på räknare innebar en ökning av 0,7mm/h, som det ser ut vid första tillfället.
Sen säger displayen 3,9 vilket inte är delbart med 0,7, och där raserade hela min teori.

Är det någon som ser ett samband. Börjar bli lite mosig i skallen nu efter någon timme debuggande :)
Skulle 1 bit på räknaren kunna motsvara 0,79mm och visningen ställd att enbart visa en decimal, men ej avrunda?

Sida 2 av 5 Alla tidsangivelser är UTC + 1 timme
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/