Fórum témák
» Több friss téma |
Sziasztok!
Némi segítséget szeretnék kérni a GPS SIRF protokoll megértéséhez. Egy GPS modult szeretnék tetszés szerinti működésre bírni, egyelőre próbapanelen. A modullal a SIRFdemo 3.81 programmal próbálok szót érteni, egyelőre nem sok sikerrel. Arra már rájöttem hogy az egyes funkciókat állítani csak akkor tudom ha az NMEA protokolról átváltok SIRF protokollra. Jelenleg két számítógépet kötöttem össze a sorosporton keresztül (sirfdemo program / BrayTerminal) hogy "élőben" lássam milyen adatot küld a demoprogram az egyes funkciók állításakor. (ezeket a hexa adatokat küldtem volna én is PIC el a modul felé...) De pl. ha ugyanazt a funkciót küldöm ugyanazokkal a beállításokkal egymás után többször, a terminal programban azt látom hogy a küldött hexa adatok nem egyeznek meg az előzőleg küldött adatokkal. Az első 4 érték egyezik, a többi teljesen más mint amit előzőleg küldött a program. Ez miért van? Tudna valaki segíteni ebben?
SIRF leírás: link.
Ha jól tudom, a formátuma: start - üzenethossz - üzenet - checksum - stop, ebből: - start: 2 byte, 0xA0A2 - hossz: 2 byte - checksum: 2 byte, üzenet byte-jain végzett XOR, majd eredmény AND 0x7FFF - stop: 2 byte, 0xB0B3 Vagyis ha valami változik, az az üzenethossz - üzenet - checksum lehet. Nincs valami üzenetszámláló is beépítve a byte-ok közé? Csak egy-két parancsnál lesz eltérésed, vagy mindegyiknél?
Egyenlőre a trickle power t állítgatom és a push to fix funkciót kapcsolom ki / be, ugyanazokkal a paraméterekkel. Minden adatküldéskor más adatok jönnek....
Continuous üzemmód kiválasztása:
A0 A2 00 09 97 00 00 03 E8 00 00 00 C8 02 4A B0 B3 A0 A2 00 99 A7 00 00 75 30 00 04 93 E0 00 00 07 08 00 00 00 FC 00 F8 00 00 00 80 E0 E0 02 D2 B0 B3 következő küldéskor: B8 A2 00 09 97 00 00 03 E8 00 00 C8 02 4A B0 BB A0 A2 00 19 A7 00 FC 75 30 80 04 93 E0 00 00 07 08 00 00 00 00 00 00 80 00 00 FE FE 00 02 DA B0 B3 van egyezés, de az adatok között vannak + adatok amiknek a miértjét nem igazán értem. Miért nem állandó formátumú a parancs?
A második üzenet miért kezdődik B8-al, A0 helyett? Ilyet még a referenciában sem találtam nagy hirtelen.
A szekvencia sem tetszik, de lehet, félreértem: bekapcsoláshoz 97 00 01 stb., folyamatos üzemhez 97 00 00 kellene a leírás szerint. Ha terminálból direktben küldesz eszerint, vajon akkor mi történik?
Ezt a "B8" at én sem igazán értem...Eddig fel sem tünt, csak most hogy rákérdeztél. Ahhoz hogy a modulnak tudjak küldeni a terminalból, szét kell kössem a 2 gépet és rá kell varrnom a kábel végére a modult... Mindjárt megoldom és kipróbálom.
Ha visszaküldöm egy az egyben a terminalból az adatot, akkor végrehajtja a modul az utasítást.
Ez a "B8" valószínűleg csak véletlenül "becsúszott" a kommunikációba valami miatt, mert azóta sem jött elő...
Akkor - szerintem - a SIRFDemo hibázik vagy a protokollal (nem kellene), vagy a soros port beállításával (ezt sem kellene), vagy maga a soros port nem díjazza az adott beállításokat (a port pufferelését Eszközkezelőből esetleg kikapcsolhatod, és úgy is megpróbálhatod a progival). Ha a mostani és az előző soros porti kábelek között nincs említhető különbség, akkor ennyi jutott eszembe.
Köszönöm a segítséget, remélem elboldogulok valahogy.
Tanulmányozd a protokollt
Némelyik adat 15 bites!
Tanulmányozom, de minél többet olvasgatom annál nagyobb a káosz a fejemben...
 Mégsem működik az adatok visszaküldése a terminal programmal. A következőképpen próbálgatom..A két PC összekötve soroson, az egyiken a SIRFdemo program fut a másikon a bray terminal. Bekapcsolom a demoprogrammal pl a "static navigation" opciót, a hexa adatsorozat meg is érkezi szépen a bray terminalra. Ha viszont ugyanezt az adatot küldöm el a GPS modulnak a terminal programmal , nem veszi tudomásul a modul, nem hajtra végre a parancsot. A soros kapcsolat jó mert látom hogy küldi a modul a műhold adatokat hexában. Lekérdezem a "poll" fül alatt a modul állapotait és "static nav : disabled" , tehát nem hajtotta végre a modul az utasítást. Valamit rosszul csinálok csak tudnám mi az...
Hát ez nagyobb szenvedés mint gondoltam...A referencia dokksiból néztem ki az adatokat amit küldök és mégsem megy. A StaticNav funkció (azért választottam ezt mert rövid az üzenet..) bekapcsolása:
A0 A2 00 02 8F 01 00 90 B0 B3 ezt küldöm a GPS modulnak, de rá sem bagózik. Ha a demoprogramból küldöm ugyanezt, ( párhuzamosan nézem a terminalon hogy mit küld a program a modul felé) akkor rendben végrehajtja.
Tudnál egy olyan printscreen-t csinálni, amin rajta van először a demó küldése (és a válasz), majd az általad hiába küldött adat is? És lehet, hogy egy rajz is elkelne arról a (gondolom én) T-adapterről, amivel összekötötted a két gépet és a modult.
Most kicsit átszerveztem a dolgokat, felprogramoztam egy PIC 16F628A - t, gombnyomásra küldi a StaticNav bekapcsolásához szükséges adatokat. De így sem megy...
Lehet hogy nem kéne beleszólnom de így látatlanba az adatok küldése között eltelt időbe lehet a kutya elásva. Lehet nincs ideje a gps- modulnak feldolgozni azokat. Próbáltál valami késleltetést?
Ezt hogy érted? A demo program is 57600 al küldi az adatokat...gondolom pufferbe rakja a modul, mert közben meg jönnek befelé is az adatok ugyanilyen sebességgel. Esetleg az egyes hex adatok közé rakjak be NOP okat...?
Igen a hex adatok közé tenni egy kis késleltetést. Logikai analizátoron kellene megnézni van e valami különbség az általad kiküldött sorozat időzítéseibe és a demóprograméba.
Lehet, hogy ez most egy idióta kérdés lesz, és csak azért teszem fel, mert eddig nem futottam bele, és nem ismerem a port-monitor programot sem: a modulban lévő processzor big-endian kódolást használ, illetve vár el - de mi a helyzet a PC (vagy PIC) oldalán? (Tudtommal az x86 little-endian-t használ). Előfordulhat az, hogy a monitorprogi egy "igazított", de valójában félreértelmezett adatsort mutat a fizikai valóság helyett?
Össze kellene kötni a PIC-et a demóprogrammal, és úgy kapcsolódni hozzá, aztán amit a PIC fogad, gondolkodás nélkül küldje is vissza. GPS ugyan nem lesz elérhető eközben, de hátha mutat valamit... Szerk.: a neten írnak mindenfélét, de több oldalon láttam, hogy vagy 4800 bps, vagy 38400 bps kell(ene). Ezt még azért kipróbálnám.
"big-endian kódolást használ...stb " Hűűű..ez a léc nekem már magas kicsit...
 Ez egy UM406 GPS modul, SIRF üzemmódban 57600 ra áll be automatikusan, de ezt tudom állítani a demo programban. De ha nem lenne jó az adatsebesség nem látnám a bejövő adatokat sem...
Nem azt írtam, hogy a többi sebesség rossz lenne
Volt vagy három olyan oldal, ahol állítólagos fejlesztők (mert mintakód bemutatása, az aztán sehol) írtak az eredményeikről, ott említették kifejezetten ezt a kettőt, bár olvastam olyan lapot is, ahol ezen kettő között bármit megengedtek. Végül is más sebességgel is látszik a transzfer, csak éppen olvashatatlan. Byte-sorrendek
Azt hogy a PIC től miért nem fogad el adatot már megfejtettem. Elsődleges hibaként az van hogy 57600 on a PIC teljesen más értéket küld mint amit kellene. 9600 on már jó. 57600 on közel 8,5% a hibalehetőség az adtlap szerint. A soros portot 4 MHz belső órajellel asyncron módban járatom, az SPBRG értéke (BRGH=1) dec . 3 ra van állítva a sorosport konfigjában. Ez 57600 nak felel meg, mégsem jó. Újabb megoldandó feladat...
Köszi az eddigi segítséget, "az a" program nagyon szuper!! Kicsit félreteszem a témát mára és megpróbálom elméletben végig gondolni hogy mi lehet a gond.
Sziasztok,
Van egy kérdés a fejemben, nem világos a dokumentációkból eléggé, bizonyára valaki már találkozott vele: NMEA módban meg lehet adni hogy milyen üzeneteket milyen gyakran küldjön ki a modul. (Quectel L50 v2.0) Nekem csak a ZDA kellene, illetve ennek SIRF bin. megfelelője, amit az 1PPS kiadása után küld. Na mármost SIRF protokollnál nincs lehetőség választani mit küld ki, legalábbis én így látom a dokumentációból. De NMEA protokolnál lehet választani, azaz kikapcsolni minden más üzenetet. Az a kérdésem, hogy ha én kikapcsolom NMEA alatt, és ezután átváltok SIRF bin. protokollra, akkor csak az 1PPS utáni időt küldi ki majd a mondul, vagy nem? |
Bejelentkezés
Hirdetés |
