[C++] Data uitlezen uit seriele poort op CTS pin.

[Graaf]

Ik probeer al aardig wat daagjes onder linux data uit te lezen uit een zo genaamde FlexBox.
Een P2000 ( brandweer, ambulance e.d. paging systeem ) ontvanger waar een zgn discriminatoruitgang op zit en middels een 2-level FSK Interface (Hamcomm modem) ruwe data uitpoept op de CTS pin van de seriele poort.
http://www.discriminator.nl/hamcomm/index.html

Een quote van een ander forum vandaan over het signaal:

Het FLEX-signaal wordt rechtstreeks en zonder aan de UART gerelateerde timing aan CTS aangeboden.

Er zijn globaal twee manieren om de CTS-poort te bemonsteren:

1. Laat een timer een aantal keer per bittijd een interrupt genereren. Bekijk in de interruptroutine de status van CTS.
2. Laat een timer lopen. Zorg ervoor dat een verandering van CTS een interrupt genereert. Lees de timer uit en reset deze.

Hier ben ik dus al enige dagen mee bezig om onder linux deze ruwe data uit te lezen om dan te decoden naar de paging meldingen die langs komen.

De normale manieren op met c++ onder linux data uit te lezen uit de seriele poort werken niet, komt geen enkele byte voorbij.

int fd = open("/dev/ttyS0", .....);
read(fd, buf, 1024);

Ook via tools als minicom geprobeerd, komt geen data uit.
Het appraat gebruikt dus niet de normale standaard manieren om communicatie via seriele poort te doen.

Onder dos is er een applicatie genaamd POCFLEX beschikbaar die dit kan.
Originele (dos) Borland C++ code van 'POCFLEX': ( vieze code!!)
http://www.kernelcoders.com/flex.txt

Ik ben maar begonnen met diverse pogingen om deze source gedeeltelijk om te schrijven naar gnu c, zonder suc6.
Of ik krijg 0 bytes terug, of het zijn segmentation faults.

Zelfs het compilen van de originele POCFLEX source onder dos met Borland Turbo C++ 3.0 geeft een executable die alleen maar Abnormal Program Termination kan zeggen.

Heeft er iemand ervaring hoe je onder linux zoiets als dit kan doen?

[GX]

Hoe heb je buf gedefinieerd?

[Graaf]

GX schreef op maandag 11 december 2006 @ 12:22:
Hoe heb je buf gedefinieerd?

In dit geval was buf een char buf[1024];
Maar er komt gewoon geen data uit op de normale manier voor seriele communicatie.

[GX]

Als je een char buf[1024] definieert en het zo gebruikt gaat het op 2 punten fout:

• read verwacht een char POINTER, dus je moet &buf doen, of char *buf = (char*)malloc(1025); doen.
• Je vergeet ruimte voor de NULL byte achteraan de string. char buf[1025] is zinniger.

Dat er geen data uitkomt weet ik zo 1-2-3 niet; maar segfaults (zoals in je startpost stond aangegeven) komen door dit soort dingen.

[ Voor 19% gewijzigd door GX op 11-12-2006 12:34 ]

[Graaf]

GX schreef op maandag 11 december 2006 @ 12:34:
Als je een char buf[1024] definieert en het zo gebruikt gaat het op 2 punten fout:

• read verwacht een char POINTER, dus je moet &buf doen, of char *buf = (char*)malloc(1025); doen.
• Je vergeet ruimte voor de NULL byte achteraan de string. char buf[1025] is zinniger.

read(fd, &buf, 1024); heb ik ook geprobeerd.
Ook om gewoon maar 1 byte op te laten halen geprobeerd.

Er komt geen data op de normale manier voor seriele communicatie uit.
Op de CTS pin komt data uit.

[GX]

Een read op je ttyS# is gewoon een normale methode, als er geen data uitkomt zit er niets op; heb je al andere poorten geprobeert? Mijn laptop vind al dat ik ttyS0 t/m ttyS3 heb, misschien bij jou ook wel.

Los daarvan is je methode hier opgeschreven de C-manier, niet de C++ manier, probeer eens iets met de stream-classes.

[Le Mol]

Snap ik het nu verkeerd, of zal je nooit je CTS pin data krijgen door uit /dev/ttySx te lezen? Zover ik weet komt hier alleen de ontvangen data op de RxD pin terecht?

[Creepy]

Je zult inderdaad m.b.v. directe I/O de status van de pin moeten uitlezen. Aangezien alleen deze pin veranders zal je niet direct karakters via /dev/whatever kunnen lezen.

[MerijnB]

lijkt me ook, daarbij is CTS geen datalijn maar wordt gebruikt voor flow control.
Uit de quote die TS heeft gepaste lijkt haast dat die FlexBox de cts gebruikt om bit voor bit data over te sturen, dit zou wel vrij bizar zijn.
Weet je iets over bitrates, stopbits, etc?

[Graaf]

Zoals ik ook al eerder aangaf betreft het hier geen communicatie op de manier zoas het standaard zou moeten gaan via de seriele poort.

De FlexBox heeft continue output op de CTS pin.

[Graaf]

Creepy schreef op maandag 11 december 2006 @ 13:42:
Je zult inderdaad m.b.v. directe I/O de status van de pin moeten uitlezen. Aangezien alleen deze pin veranders zal je niet direct karakters via /dev/whatever kunnen lezen.

Volgens mij moet ik idd in deze richting gaan denken.
Daar ze volgens mij in die sourcecode van POCFLEX ook niet een com poort direct openen, maar met allerlij adressen e.d. aan de gang gaan.

Ik heb alleen geen flauw idee hoe dit te doen is onder linux.

Heb er niks over kunnen vinden.

[mvdklip]

MS-DOS heeft geen Hardware Abstraction Layer, vandaar dat je direct bij de hardware kan vanuit je programma. Ik ben niet 100% zeker, maar ik zou zeggen dat je in een moderner besturingssysteem toch echt een driver danwel kernel module zal moeten schrijven om direct bij de hardware te kunnen.

In mijn goede oude demotijd schreef ik ook allerlei code die direct data in hardwareregisters stopte etc. Windows 9x emuleert dit nog voor een deel, maar die zelfde demo's lopen toch echt voor geen meter onder Windows NT/XP etc.

Edit: op http://www.discriminator.nl/start/ zie je ook duidelijk dat er een "slicer" driver geinstalleerd wordt onder Windows voor het PDW programmaatje. Ik vermoed dat deze voorziet in ruwe toegang tot de seriele poort.

[ Voor 17% gewijzigd door mvdklip op 11-12-2006 14:13 ]

[Graaf]

mvdklip schreef op maandag 11 december 2006 @ 14:06:
MS-DOS heeft geen Hardware Abstraction Layer, vandaar dat je direct bij de hardware kan vanuit je programma. Ik ben niet 100% zeker, maar ik zou zeggen dat je in een moderner besturingssysteem toch echt een driver danwel kernel module zal moeten schrijven om direct bij de hardware te kunnen.

In mijn goede oude demotijd schreef ik ook allerlei code die direct data in hardwareregisters stopte etc. Windows 9x emuleert dit nog voor een deel, maar die zelfde demo's lopen toch echt voor geen meter onder Windows NT/XP etc.

Edit: op http://www.discriminator.nl/start/ zie je ook duidelijk dat er een "slicer" driver geinstalleerd wordt onder Windows voor het PDW programmaatje. Ik vermoed dat deze voorziet in ruwe toegang tot de seriele poort.

Ok. Dus ik zou een driver/module kunnen gaan ( proberen ) schrijven voor de directe hardware toegang op die ene pin.
Maar dan kan ik dat toch netzogoed inprogrammeren in de applicatie zelf die de data zou moeten uitlezen en decoderen enzo?
Of gaat een driver/module net even een paar laagjes dichter op de harware zitten?

[igmar]

Creepy schreef op maandag 11 december 2006 @ 13:42:
Je zult inderdaad m.b.v. directe I/O de status van de pin moeten uitlezen. Aangezien alleen deze pin veranders zal je niet direct karakters via /dev/whatever kunnen lezen.

Hetgeen hierboven klopt echt niet. Dat zou concreet betekenen dat een applicatie als minicom altijd met root privs moet draaien, aangezien direct I/O ioperm() ed betekend.

Linux heeft voor seriele communicatie een mooie API, en daarmee kun je ook de status van de modem controls uitlezen. Google

The hardware modem control lines can be monitored or modified by the
ioctl(2) system call. A set of comparable tc* calls apparently do not
exist. The form of this call is:

int ioctl( fd, COMMAND, (int *)flags );
....
TIOCMGET the appropriate bits are set in flags according to the
current status

[farlane]

igmar schreef op maandag 11 december 2006 @ 14:51:
Linux heeft voor seriele communicatie een mooie API, en daarmee kun je ook de status van de modem controls uitlezen. Google

Het sturen van ioctl's kan ik niet bepaald mooi noemen. Het werkt, dat wel.

[Creepy]

igmar schreef op maandag 11 december 2006 @ 14:51:
[...]


Hetgeen hierboven klopt echt niet. Dat zou concreet betekenen dat een applicatie als minicom altijd met root privs moet draaien, aangezien direct I/O ioperm() ed betekend.

Linux heeft voor seriele communicatie een mooie API, en daarmee kun je ook de status van de modem controls uitlezen. Google


[...]

Eeh.. hoe je directe IO doet met de comm. poort heb ik niet verteld Of dat nu met een ioctl, inb() of tcsetattr() doet maakt wat dat betreft geen verschil. Ik heb alleen gezegd dat je niet een /dev/whatever kan openen en hier direct karakters van kan lezen (zoals nu in de TS gebeurt) om zo een status pin uit te lezen.

Daarnaast kan je voor normale seriele communicatie wel degelijk op een "normale" manier karakters lezen en schrijven (again, zoals in de TS gebeurt). De driver zal nu het flow control gebeuren voor je afhandelen. Maar bit banging op een status pin wil ik nu geen normale seriele communicatie noemen voor een normale seriele poort op een PC.

[ Voor 28% gewijzigd door Creepy op 11-12-2006 15:59 ]

[igmar]

farlane schreef op maandag 11 december 2006 @ 15:10:
Het sturen van ioctl's kan ik niet bepaald mooi noemen. Het werkt, dat wel.

En wat is daar niet mooi aan ? Goed, de mogelijk void * arg is dan misschien niet zo netjes, maar altijd nog beter als voor elke operatie een aparte functie schrijven.

[igmar]

Creepy schreef op maandag 11 december 2006 @ 15:50:
Eeh.. hoe je directe IO doet met de comm. poort heb ik niet verteld Of dat nu met een ioctl, inb() of tcsetattr() doet maakt wat dat betreft geen verschil. Ik heb alleen gezegd dat je niet een /dev/whatever kan openen en hier direct karakters van kan lezen (zoals nu in de TS gebeurt) om zo een status pin uit te lezen.

Directe IO noem ik toch echt rechtstreeks de IO poorten benaderen. Voor de meeste serieele communicatie zal je het niet redden met alleen een open() op de ttyS? poort.

Daarnaast kan je voor normale seriele communicatie wel degelijk op een "normale" manier karakters lezen en schrijven (again, zoals in de TS gebeurt). De driver zal nu het flow control gebeuren voor je afhandelen. Maar bit banging op een status pin wil ik nu geen normale seriele communicatie noemen voor een normale seriele poort op een PC.

alleen een read / write zal resulteren in een communicatie met de op dat moment actieve parameters. Niet echt wat je wilt vaak. Bitbangen op de modem controls is nou niet bepaald een degelijk ontwerp nee :-) iig : Hij zal de ioctl() moeten gebruiken, en in een loopje pollen. select() en familie zijn niet bruikbaar.

[Verwijderd]

Heb je hier al gekeken? : http://www.linuxjournal.com/article/6226, http://www.linuxjournal.com/article/7000 en
http://www.linuxjournal.com/article/5896

[Graaf]

Hm ok. Thanx voor de info iig.

Nou er achter zien te komen hoe ik dan via ioctl data ga uitlezen...
Zijn daar concrete voorbeelden van?
En hoe je dan van de CTS de data kan pakken?

[Verwijderd]

Kun je niet gewoon de CTS aansluiten op de RXD van jouw terminal? Gewoon proberen.

[Graaf]

Verwijderd schreef op maandag 11 december 2006 @ 20:38:
Kun je niet gewoon de CTS aansluiten op de RXD van jouw terminal? Gewoon proberen.

Ik vond een seriele verlengkabel en heb eventjes zitten solderen.
Als ik nu een cat /dev/ttyS0 doe, dan zie ik meuk



Je kan ook precies zien het momentum waar er een melding (bericht) binnenkwam, tussen de ruis door.

[Verwijderd]

LOL, toen ik de schema op discriminator.nl zag ik geen reden dat dit niet zou moeten werken..

suc6

[Graaf]

Verwijderd schreef op maandag 11 december 2006 @ 21:35:
LOL, toen ik de schema op discriminator.nl zag ik geen reden dat dit niet zou moeten werken..

suc6

Thanx.

Nou zou ik iig dit weop middels open(..) en read(..) kunnen gaan aanpakken dus?
Op goed geluk dan maar, kijken of het gaat lukken om die data uit te lezen naar iets bruibaars

[Graaf]

Jammergenoeg gaat dit niet werken waarsch.

Ontvanger data-output : FLEX 1600 bps(P2000 protocol)
1600bps, dat is waarsch de reden waarom ze op de CTS pin zitten?

D'r is geen touw aan vast te knopen als ik via de RxD data probeer uit te lezen.

Terug naar af. Data inlezen via de CTS pin.

Wat ik tot zover weet is dat ik dit het beste via ioctl's zou kunnen doen.
Ik heb nog niet kunnen begrijpen door lezen van o.a. links gepost eerder hoe je via ioctl's data kan uitlezen uit de seriele poort.

[Verwijderd]

Zijn gewoon 1-tjes en 0-lletjes. Die discriminator zorgt daar wel voor. Kun je niet cat /dev/ttys0 > /home/media/flex/capture.dat doen en die file lezen in een hex editor? Dan die file decoderen met het p2000 protocol? Ik denk alleen dat je die seriele poort moet instellen op 1600bps. Je hebt geen flow control dus je moet wel vaak de buffers lezen van de UART, anders zul je data kwijt raken.

Zie: http://www.tldp.org/HOWTO/Serial-HOWTO-12.html#set_serial

[Graaf]

Verwijderd schreef op dinsdag 12 december 2006 @ 07:14:
Zijn gewoon 1-tjes en 0-lletjes. Die discriminator zorgt daar wel voor. Kun je niet cat /dev/ttys0 > /home/media/flex/capture.dat doen en die file lezen in een hex editor? Dan die file decoderen met het p2000 protocol? Ik denk alleen dat je die seriele poort moet instellen op 1600bps. Je hebt geen flow control dus je moet wel vaak de buffers lezen van de UART, anders zul je data kwijt raken.

Zie: http://www.tldp.org/HOWTO/Serial-HOWTO-12.html#set_serial

Volgens mij is dat het probleem juist, die 1600bps.
Seriele poort krijg je niet op 1600bps. ik niet iig.

[farlane]

Graaf schreef op dinsdag 12 december 2006 @ 07:33:
Volgens mij is dat het probleem juist, die 1600bps.
Seriele poort krijg je niet op 1600bps. ik niet iig.

Bovendien is een standaard RS232 signaal niet een FSK signaal.

igmar schreef op maandag 11 december 2006 @ 16:34:
En wat is daar niet mooi aan ?

Het is een algemene manier om 'informatie' naar een driver te krijgen zonder te specificeren hoe de informatie eruit moet zien. Nadeel daarvan is dat het heel algemeen is

Ik zou liever zien dat er voor dit soort dingen een standaard API aanwezig is, net zoals je die onder Win32 hebt. ( die onder water ongetwijfeld weer naar ioctls wordt vertaald )
Tis niet zo dat dit soort dingen bijna nooit voorkomen namenlijk. Vergelijk het een beetje met bijvoorbeeld het instellen van parity en dat soort dingen onder Linux, je kunt dat doen door zelf met allerlei bitjes en masks en weet ik het wat te pielen maar er is ook een shortcut die een 1 keer je port naar raw mode zet.

[edit]
spelling

[ Voor 60% gewijzigd door farlane op 12-12-2006 10:55 ]

[Graaf]

Toch blijf ik het vreemd vinden dat er nog nooit iemand op linux platform hieraan heeft gewerkt.
2-level FSK .... op de CTS pin uitlezen.

Ik ken ondertussen heel google uit m'n kop met de hoeveelheid zoek-opdrachten die ik gedaan heb afgelopen dagen. ( bij wijze van )

ik ben verder vrij onbekend met ioctl's, dus weet ook niet zo goed waar ik moet beginnen op 't moment .

[farlane]

Graaf schreef op dinsdag 12 december 2006 @ 10:54:
ik ben verder vrij onbekend met ioctl's, dus weet ook niet zo goed waar ik moet beginnen op 't moment .

Het grote probleem hierbij is de hoeveelheid docs die er te vinden zijn Kijk ff naar dit voorbeeld:

C:

    // Get current control line status
    if( ioctl( port->fd, TIOCMGET, &status ) == -1 )
        return -1;

Waarbij port->fd de file descriptor is van je seriele poort.

Je kunt daarna een mask over status leggen om te zien welke pinnen hoog/laag zijn. Voor de CTS pin is dat TIOCM_CTS

Wil je meer weten doe dan maar eens een grep op dat mask in je linux include dir


[edit]
kijk hier maar eens naar
http://xgen.iit.edu/cgi-bin/man/man2html?tty_ioctl+4

[ Voor 6% gewijzigd door farlane op 12-12-2006 11:03 ]

[Graaf]

farlane schreef op dinsdag 12 december 2006 @ 11:01:
[...]


Het grote probleem hierbij is de hoeveelheid docs die er te vinden zijn Kijk ff naar dit voorbeeld:

C:

    // Get current control line status
    if( ioctl( port->fd, TIOCMGET, &status ) == -1 )
        return -1;

Waarbij port->fd de file descriptor is van je seriele poort.

Je kunt daarna een mask over status leggen om te zien welke pinnen hoog/laag zijn. Voor de CTS pin is dat TIOCM_CTS

Wil je meer weten doe dan maar eens een grep op dat mask in je linux include dir


[edit]
kijk hier maar eens naar
http://xgen.iit.edu/cgi-bin/man/man2html?tty_ioctl+4

Ok.

Waar het dan dus eigenlijk op neer komt is dat ik op die CTS pin alleen maar 0 en 1 kan uitlezen.
Waar ik dan per groepje 0'en en 1'en ( 0110 1001 is dan 2 byte dat weer overeen komt met 0x## ) kan bepalen wat de byte waarde is.

Deze kan ik dan weer decoden naar het uiteindelijke bericht.

Die 0 en 1tjes die lees ik uit door te kijken of de CTS pin 'aan' of 'uit' is dan.

[farlane]

Jup. Je krijgt een rits bitjes die je moet decoderen naar characters. ( iets dat de serieele poort normaal gesproken voor je doet )

Je moet dat FSK verhaal kennen om dit te doen ( iets dat dat PDW programma normaal gesproken doet dus ) en das als ik de code uit jouw voorbeeld bekijk nie echt makkelijk.

Bedenk ook dat de timing die je zult bereiken niet te vergelijken is met een DOS applicatie. Je hebt een bittijd van 625 us dus ik betwijfel of je het aan de praat krijgt.

[Graaf]

farlane schreef op dinsdag 12 december 2006 @ 13:51:
Jup. Je krijgt een rits bitjes die je moet decoderen naar characters. ( iets dat de serieele poort normaal gesproken voor je doet )

Je moet dat FSK verhaal kennen om dit te doen ( iets dat dat PDW programma normaal gesproken doet dus ) en das als ik de code uit jouw voorbeeld bekijk nie echt makkelijk.

Bedenk ook dat de timing die je zult bereiken niet te vergelijken is met een DOS applicatie. Je hebt een bittijd van 625 us dus ik betwijfel of je het aan de praat krijgt.

Mja ok. Er gaat veel uitzoek werk in zitten over het FLEX protocol e.d.
Startbitjes, Stopbitjes enzovoorts..

Maar als ze onder windows een programma hebben ( PDW ) en onder dos ( POCFLEX ) dan moet het toch ook onder linux kunnen lijkt me.

[Belgar]

farlane schreef op dinsdag 12 december 2006 @ 13:51:
Jup. Je krijgt een rits bitjes die je moet decoderen naar characters. ( iets dat de serieele poort normaal gesproken voor je doet )

Je moet dat FSK verhaal kennen om dit te doen ( iets dat dat PDW programma normaal gesproken doet dus ) en das als ik de code uit jouw voorbeeld bekijk nie echt makkelijk.

Bedenk ook dat de timing die je zult bereiken niet te vergelijken is met een DOS applicatie. Je hebt een bittijd van 625 us dus ik betwijfel of je het aan de praat krijgt.

kort door de bocht: 4800 bps = 3* 1600 bps (9600 = 6x 1600). als je rdx gebruikt of een andere oplossing zou je dus wel de hardware timing kunnen gebruiken.

[farlane]

Graaf schreef op dinsdag 12 december 2006 @ 15:58:
Maar als ze onder windows een programma hebben ( PDW ) en onder dos ( POCFLEX ) dan moet het toch ook onder linux kunnen lijkt me.

Mja maar zoals ik al zei heeft die windows versie een speciale COM poort driver nodig. Als dat ding de decoding doet heb je wat andere timing dan in user space.

[farlane]

Belgar schreef op dinsdag 12 december 2006 @ 16:58:
[...]


kort door de bocht: 4800 bps = 3* 1600 bps (9600 = 6x 1600). als je rdx gebruikt of een andere oplossing zou je dus wel de hardware timing kunnen gebruiken.

Waarschijnlijk niet want die FSK encoding is waarschijnlijk anders dan de RS232 encoding

Graaf schreef op dinsdag 12 december 2006 @ 17:04:
Oplossing:
Kerneldriver/module schrijven die het zelfde doet als die windows driver.
De bitjes van de CTS pin omzetten naar bytes en dat outputten naar een device.

Mja, vooral dat kernel mode gedeelte kon nog wel eens een opdracht van formaat worden, hoe moeilijk is dat?

[ Voor 34% gewijzigd door farlane op 12-12-2006 17:07 ]

[Graaf]

farlane schreef op dinsdag 12 december 2006 @ 16:58:
[...]


Mja maar zoals ik al zei heeft die windows versie een speciale COM poort driver nodig. Als dat ding de decoding doet heb je wat andere timing dan in user space.

Oplossing:
Kerneldriver/module schrijven die het zelfde doet als die windows driver.
De bitjes van de CTS pin omzetten naar bytes en dat outputten naar een device.

[Graaf]

farlane schreef op dinsdag 12 december 2006 @ 17:02:

Mja, vooral dat kernel mode gedeelte kon nog wel eens een opdracht van formaat worden, hoe moeilijk is dat?

Zo'n driver/module zelf schrijven is nog wel te doen, alleen de inhoud wat pittiger.
Dus het daadwerkelijk omzetten van alles.

De dos applicatie POCFLEX doet iets met interrups en de CTS pin, ik heb 0,0 verstand van asm dus ik begrijp niet helemaal hoe en wat ze daar doen. Daarbuiten, interrupts heb ik ook weinig brood van gegeten. Altijd mooi om nieuwe dingen te leren.

Ik zat zelf te denken naar een kernel module, zodat ik niet telkens hoef te rebooten na een rebuild , die omgezette data (bytes) output naar een /dev/customdinggeval bijv.

Iets om de winter mee door te komen

[MSalters]

Is het niet handiger om een FreeDOS microcontroller te vinden? Ik weet dat die bestaan; ongeveer 40x40x20 mm, met seriele en netwerk poort, en Borland C++ inbegrepen. Mik de POCFLEX meuk daarop, zet er een TCP interface op, en vergeet het ding verder.

[Graaf]

MSalters schreef op dinsdag 12 december 2006 @ 20:22:
Is het niet handiger om een FreeDOS microcontroller te vinden? Ik weet dat die bestaan; ongeveer 40x40x20 mm, met seriele en netwerk poort, en Borland C++ inbegrepen. Mik de POCFLEX meuk daarop, zet er een TCP interface op, en vergeet het ding verder.

Hmmm nee

Ik wil linux omdat ik meer wil dan alleen maar op een beeldscherm kijken, of text log files parsen op een windows / dos bak.
Er is hier in huis ook maar non linux/mac systeem en dat is die van m'n vriendin.

Aangezien er bar weinig voor linux is te vinden hierover, wil ik het o.a. daarom doorzetten.

Ik heb nu iig al voorelkaar dat ik een soort van kernel module heb die elke CTS change registreerd, en daarvan de status uitleest: low/high.

Nou moet ik dit nog om gaan zetten in bytes.. ( en de tijd tussen de changes meten om de overige bitjes op te vullen )

Die berekeningen worden ook nog wel ingewikkeld ....

[farlane]

Graaf schreef op dinsdag 12 december 2006 @ 21:24:
Ik heb nu iig al voorelkaar dat ik een soort van kernel module heb die elke CTS change registreerd, en daarvan de status uitleest: low/high.

Op interrupt? ( waarschijnlijk haal je anders de gevraagde timing niet. ) Een microcontroller is anders zo gek nog niet trouwens. Deze kun je zelf programmeren inc FSK decoding, je timing zit dan helemaal goed. Je gooit het spul over de serieele poort naar buiten en maakt een mooi linux progje die weet ik wat met die data doet. Lijkt me wel leuk eigenlijk; je zou eventueel een aagepaste schakeling van dat kastje kunnen gebruiken om je signaalniveaus naar TTL te krijgen. Leuk hobby werk

Iets om de winter mee door te komen

Das waar

[Graaf]

farlane schreef op dinsdag 12 december 2006 @ 23:58:
[...]


Op interrupt? ( waarschijnlijk haal je anders de gevraagde timing niet. ) Een microcontroller is anders zo gek nog niet trouwens. Deze kun je zelf programmeren inc FSK decoding, je timing zit dan helemaal goed. Je gooit het spul over de serieele poort naar buiten en maakt een mooi linux progje die weet ik wat met die data doet. Lijkt me wel leuk eigenlijk; je zou eventueel een aagepaste schakeling van dat kastje kunnen gebruiken om je signaalniveaus naar TTL te krijgen. Leuk hobby werk


[...]


Das waar

Ik vermoed dat dat iets meer hardware en programmeer kennis vergt dan dat ik heb. ( en zal ook wel een aantal winters duren )

Ik dacht dat ik goed op weg was, maar iik heb net een hele berg bitjes ziten analyseren. Helaas kom ik nergens iets tegen wat op het begin van een melding lijkt.
Uitlezen van bitjes gaat dus nog niet goed

[ Voor 13% gewijzigd door Graaf op 13-12-2006 00:53 ]

[farlane]

Graaf schreef op woensdag 13 december 2006 @ 00:14:
Ik dacht dat ik goed op weg was, maar iik heb net een hele berg bitjes ziten analyseren. Helaas kom ik nergens iets tegen wat op het begin van een melding lijkt.
Uitlezen van bitjes gaat dus nog niet goed

Ik denk dat je idd eerst moet zorgen dat je bitjes binnekomen zoals ze verstuurd worden. Ik zie eigenlijk geen andere methode dat met een scope kijken op de lijn en dat vergelijken met wat je binnenkrijgt.

[Graaf]

farlane schreef op woensdag 13 december 2006 @ 09:45:
[...]


Ik denk dat je idd eerst moet zorgen dat je bitjes binnekomen zoals ze verstuurd worden. Ik zie eigenlijk geen andere methode dat met een scope kijken op de lijn en dat vergelijken met wat je binnenkrijgt.

Ik heb nou eerst de cycles per bit berekend aan de hand van cpu snelheid en de snelheid van flex ( 1600bps ).

Daarna een interrupt dat elke change van de cts een handler uitvoert, waarin een timer bijhoud hoeveel cycles tussen elke verandering zitten.

Om zo de te berekenen welke bitjes op welke plaats moeten komen.

code:

        cycles_per_second =  cpu_khz*1000;
        cycles_per_bit    =  cycles_per_second/1600;  // FLEX 1600 bps

Iemand op 't scannerforum kwam met het volgende document:

http://scholar.lib.vt.edu...6/unrestricted/THESIS.PDF

Erg nuttige informatie dus! Staat ook een block diagram in over hoe je de bits moet uitlezen.
Vanavond weer aan de slag!

[ Voor 24% gewijzigd door Graaf op 13-12-2006 10:22 ]

[farlane]

Graaf schreef op woensdag 13 december 2006 @ 09:56:
[...]


Ik heb nou eerst de cycles per bit berekend aan de hand van cpu snelheid en de snelheid van flex ( 1600bps ).

Daarna een interrupt dat elke change van de cts een handler uitvoert, waarin een timer bijhoud hoeveel cycles tussen elke verandering zitten.

Om zo de te berekenen welke bitjes op welke plaats moeten komen.

code:

        cycles_per_second =  cpu_khz*1000;
        cycles_per_bit    =  cycles_per_second/1600;  // FLEX 1600 bps

Iemand op 't scannerforum kwam met het volgende document:

http://scholar.lib.vt.edu...6/unrestricted/THESIS.PDF

Erg nuttige informatie dus! Staat ook een block diagram in over hoe je de bits moet uitlezen.
Vanavond weer aan de slag!

Die thesis ziet er inderdaad nuttig uit. De 2-FSK decoding is nog redelijk simpel als ik het zo zie.

[Verwijderd]

Leuk probleem, laat mij toch niet los. Hier heb ik nog iets gevonden over ttys0 line status:

Check the condition of DTR on the serial port.

#include <termios.h>
#include <fcntl.h>
#include <sys/ioctl.h>

main() {
int fd, serial;

fd = open("/dev/ttyS0", O_RDONLY);
ioctl(fd, TIOCMGET, &serial);
if (serial & TIOCM_DTR)
puts("TIOCM_DTR is not set");
else
puts("TIOCM_DTR is set");
close(fd);

zie: http://techpubs.sgi.com/l...man/man4/tty_ioctl.4.html

[farlane]

Verwijderd schreef op woensdag 13 december 2006 @ 17:37:
Check the condition of DTR on the serial port.

We waren al een aantal steppen verder namenlijk dat het pollen op die manier niet de vereiste timing nauwkeurigheid gaat halen

[Graaf]

farlane schreef op woensdag 13 december 2006 @ 22:35:
[...]


We waren al een aantal steppen verder namenlijk dat het pollen op die manier niet de vereiste timing nauwkeurigheid gaat halen

Mja, heb alleen nogsteeds het probleem dat ik niet op de juiste manier de bits ophaal volgens mij.
Krijg het maar niet voorelkaar om het juist te doen.

Een interrupt neerzetten die bij elke bit change op de CTS een handler functie uitvoert, waarin ook weer een timer zit om zo tot een 1600 bits per seconde te komen. <- dat doe ik nu, alleen de data die het "genereerd" is niet bruikbaar.

Ben even het spoort bijster nou zegmaar

Zat eventjes te denken om het "andersom" te doen, een timer startten die 1600 keer in een seconde de CTS pin checkt.
Om zo te zoeken naar de sync sequence van een FLEX bericht.

'k bedoel, ik weet hoeveel cycles ik per bit heb.

Maarja, hoe zo'n timer te maken die niet m'n bak vast laat lopen zoals net ...

--
Onbegrijpelijk dat ik het nog leuk blijf vinden ook ... *frustratiesss*

[ Voor 21% gewijzigd door Graaf op 14-12-2006 00:56 ]

[Graaf]

Volgens mij is het me gisteren gelukt om de bitjes goed te zetten.

Ik vond een paar keer een flex sync sequence terug, dat het begin van een bericht aangeeft.
Komende dagen ga ik handmatig een logfile vol bitjes decoden om te kijken of het idd een flex bericht betreft.

Misschien weer een stapje dichterbij dus

[farlane]

1600 keer per seconde is niet genoeg om het betrouwbaar te bemosteren, je minstens 2x zo snel bemonsteren als de frequentie van je signaal ( Wet van Fourier geloof ik )

[ Voor 10% gewijzigd door farlane op 15-12-2006 11:54 ]

[Graaf]

farlane schreef op vrijdag 15 december 2006 @ 11:54:
1600 keer per seconde is niet genoeg om het betrouwbaar te bemosteren, je minstens 2x zo snel bemonsteren als de frequentie van je signaal ( Wet van Fourier geloof ik )

Ik ben doorgegaan op de andere manier.

Interrupt op CTS change, en dan bijhouden hoeveel cycles tussen de changes zitten.
Op die manier kan ik zelf berekenen hoeveel bits per seconde ik wil hebben.

[farlane]

Graaf schreef op vrijdag 15 december 2006 @ 15:00:
Ik ben doorgegaan op de andere manier.

Interrupt op CTS change, en dan bijhouden hoeveel cycles tussen de changes zitten.
Op die manier kan ik zelf berekenen hoeveel bits per seconde ik wil hebben.

Lijkt me ook beter eigenlijk.

De robuustheid van dit soort ( asynchrone ) communicatie is erg afhankelijk van hoe snel en betrouwbaar je de startsequence kunt vinden. Als het een keer mis loopt moet je snel weer de volgende sequence kunnen detecteren ( denk aan een kabel die er uitgetrokken wordt, en er weer in waarbij die eerst een hoop zooi op je input pinnen genereert ( hint ) )
Bovendien hebben sommige UART chips de neiging om bij een storing 'dood' te gaan dwz ze reageren helemaal nergens meer op totdat ze weer opnieuw geinitialiseerd worden. Je moet dus ook op dit niveau naast je CTS irq ook een char timeout timer gaan bijhouden die je sequence reset als het te lang duurt tot een volgende char binnenkomt. Denk bv aan X maal de bittime oid.

[ Voor 20% gewijzigd door farlane op 15-12-2006 15:14 ]

[Graaf]

farlane schreef op vrijdag 15 december 2006 @ 15:10:
[...]


Lijkt me ook beter eigenlijk.

De robuustheid van dit soort ( asynchrone ) communicatie is erg afhankelijk van hoe snel en betrouwbaar je de startsequence kunt vinden. Als het een keer mis loopt moet je snel weer de volgende sequence kunnen detecteren ( denk aan een kabel die er uitgetrokken wordt, en er weer in waarbij die eerst een hoop zooi op je input pinnen genereert ( hint ) )
Bovendien hebben sommige UART chips de neiging om bij een storing 'dood' te gaan dwz ze reageren helemaal nergens meer op totdat ze weer opnieuw geinitialiseerd worden. Je moet dus ook op dit niveau naast je CTS irq ook een char timeout timer gaan bijhouden die je sequence reset als het te lang duurt tot een volgende char binnenkomt. Denk bv aan X maal de bittime oid.

Mja. En volgens mij moet je met het decoden van de berichten zelf ook beetje "spelen" met de snelheid waarmee je de bits inleest.

Zit nu alleen beetje vast met hoe ik nou verder moet gaan.
De interrupt voert telkens een handler uit. Dan zou ik in die handler allerlij checks moeten inbouwen die zoeken naar de syncs e.d. weet niet hoe ik dit op een andere manier zou moeten triggeren binnen een kernel module.

[farlane]

Je moet de interrupt alleen de 'bytes' laten decoderen en die bufferen denk ik anders gaat er te veel tijd zitten in die routine.

De 'frames' decoderen is een 'niveau hoger' bij wijze van spreken en zou je zelfs nog door je user mode applicatie kunnen laten doen.

Als je het heel officieel zou willen doen zou je een kernel module ( protocol filter ) kunnen maken voor deze decodering maar dat gaat voor een eerste probeersel denk ik iets te ver. Ik weet ook niet precies hoe dit in Linux geregeld is.

[Graaf]

farlane schreef op zondag 17 december 2006 @ 14:53:
Je moet de interrupt alleen de 'bytes' laten decoderen en die bufferen denk ik anders gaat er te veel tijd zitten in die routine.

De 'frames' decoderen is een 'niveau hoger' bij wijze van spreken en zou je zelfs nog door je user mode applicatie kunnen laten doen.

Als je het heel officieel zou willen doen zou je een kernel module ( protocol filter ) kunnen maken voor deze decodering maar dat gaat voor een eerste probeersel denk ik iets te ver. Ik weet ook niet precies hoe dit in Linux geregeld is.

Probleem in het maken van een kernelmodule die de bits omzet naar bytes en dan bijv output naar een custom /dev/device is denk ik dat je niet echt kan "detecteren" wanneer je het eerste bitje van een byte langs "ziet" komen.

Aangezien je de status ( laag / hoog ) van de CTS pin "uitleest", zie ik niet hoe je dit zou kunnen doen.

't Hele "projectje" ligt daarom ook stil hierdoor.

[farlane]

Graaf schreef op maandag 18 december 2006 @ 13:59:
Probleem in het maken van een kernelmodule die de bits omzet naar bytes en dan bijv output naar een custom /dev/device is denk ik dat je niet echt kan "detecteren" wanneer je het eerste bitje van een byte langs "ziet" komen.

De bedoeling is dat je dat doet mbv het sync block dat vooraan in het frame staat.

Ik heb het protocol even kort bekeken maar er staat niet het exacte formaat van het sync block in dus dat wordt wat reverse engineeren

Wat ik er wel uit kan halen is:
Elk frame begint met :
SYNC1 ( 32 bits op 1600 kbs ) wat een vast formaat is
FI ( 144-64 bits ) (frame info )
SYNC2 ( 25 ms ) zal ook een vast patroon zijn want wordt gebruikt om de receiver in te stellen

Vervolgens worden de codewoorden in een block ( 8 in totaal op 1600bps ) 'parallel' verstuurd dwz
je krijgt eerst bit 0 van codewoorden 0-7 en daarna bit 1 van codewoorden 0-7 etc

Ik zou zelf wat jij zegt gaan kijken welke bits er binnen komen en vervolgens kijken of ik herhalende patronen zou kunnen ontdekken ( SYNC1 en SYNC2 )

ALs je weet hoe die patronen eruit moeten zien kun je je driver hierop laten triggeren

Verder zie ik ook dat decoderen per byte wat lastig wordt, dus je zult per frame moeten decoderen.

[Graaf]

Het herkennen het Sync1 patroon in bits is geen probleem, dat heb ik al herkend met blote oog eentjes en nulletjes bekijken.

http://www.kernelcoders.com/flex/FLINFO.HTM

Sync Sequence is 870C A6C6 AAAA 78F3 in bytes.
Waar de buitenste 2 bijelkaar FFFF is.

[farlane]

Ok dan, dan ben je al een eindje verder

Als je een uint32_t gebruikt om deze header te herkennen schuif je de bitjes vanaf rechts in en op het moment dat deze overeenkomt met de sync sequence start je je framedecoder.

Eventuele checksums/parities etc controleer je zo snel het kan om een eventuele foute sync weg te poetsen ( dwz je gaat opnieuw naar een sync header zoeken in de data ) Het kan ook zijn dat er een bepaalde manier wordt gebruikt om te voorkomen dat een sync header in een bericht voorkomt btw, dan is de kans kleiner dat je een foute sync hebt

Al met al moet dit toch te doen zijn, er is nog best wel wat informatie over te vinden

[Graaf]

farlane schreef op maandag 18 december 2006 @ 21:05:
Ok dan, dan ben je al een eindje verder

Als je een uint32_t gebruikt om deze header te herkennen schuif je de bitjes vanaf rechts in en op het moment dat deze overeenkomt met de sync sequence start je je framedecoder.

Eventuele checksums/parities etc controleer je zo snel het kan om een eventuele foute sync weg te poetsen ( dwz je gaat opnieuw naar een sync header zoeken in de data ) Het kan ook zijn dat er een bepaalde manier wordt gebruikt om te voorkomen dat een sync header in een bericht voorkomt btw, dan is de kans kleiner dat je een foute sync hebt

Al met al moet dit toch te doen zijn, er is nog best wel wat informatie over te vinden

Het ontbreekt mij ook vooral aan ervaring met dit soort dingen.
In het dagelijks leven houd ik me bezig met javascript/html/css/php/mysql/rails/perl e.d.

[farlane]

Dan is dit de uitgelezen kans om een mee te maken wat een echte programmeur doet

[Graaf]

..
Als je een uint32_t gebruikt om deze header te herkennen schuif je de bitjes vanaf rechts in en op het moment dat deze overeenkomt met de sync sequence start je je framedecoder.
..

Wat bedoel je daar precies mee.
Bitjes vanaf rechts in een uint32_t stoppen?

Is dat in een loopje alle bitjes 1 plek naar links douwen en dan als laatste de nieuwe bit toevoegen?

[Verwijderd]

Graaf schreef op dinsdag 19 december 2006 @ 13:28:
[...]


Wat bedoel je daar precies mee.
Bitjes vanaf rechts in een uint32_t stoppen?

Is dat in een loopje alle bitjes 1 plek naar links douwen en dan als laatste de nieuwe bit toevoegen?

niet met een loopje maar:

varResultaat << 1; //schuif alle bits 1 positie op naar links


Voor het vinden van het sync sequence:

C:

unsigned int resultaat;
unsigned int gelezenBit;
int stop =0;

while(!stop){
    gelezenbit = leesWaarde();
    resultaat << 1; //schuif alle bits 1 positie op naar links
    resultaat += gelezenBit; // (waarde 0 of 1) voeg de gelezen bit toe
    if (resultaat == SYNC_SEQUENCE){ //Check of de gelezen waarde gelijk is aan de sync sequence (constante)
        startDecoder(); //start de decoder
    }

}

er van uitgaande dat de startDecoder pas returned waaneer hij de weg kwijt is. Dan zoekt de bovenstaand while een nieuwe SYNC sequence en start de decoder opnieuw

C:

void startDecoder(){
unsigned int resultaat;
unsigned int gelezenBit;
unsigned int counter = 0;
int stop =0;

while(!stop){
    gelezenbit = leesWaarde();
    resultaat << 1; //schuif alle bits 1 positie op naar links
    resultaat += gelezenBit; // (waarde 0 of 1) voeg de gelezen bit toe
    counter++; 
    if (counter == 32){ //waaneer we 32 bits in de integer gepropt hebben...
        stop = voegToeAanBuffer(resultaat); //...dan voegen we hem toe aan de buffer
        counter = 0; //counter weer resetten
        resultaat = 0; //niet echt noodzakelijk sinds alles er uiteindelijk word afgeshift, maar wel fijn met debuggen...
    }
}
}

Ik ga er hier vanuit dat de voegToeAanbuffer direct of indirect (met een andere functie) checked of de data klopt. Zoniet dan returned hij een 0 (anders een willekeurige andere waarde) waardoor de decoder stopt en hij dus weer naar een sync gaat zoeken

Hoop dat je er wat mee verder komt

PS Hopelijk de laatste edit

[ Voor 69% gewijzigd door Verwijderd op 19-12-2006 14:40 ]

[Graaf]

...stukje weggeknipt...

code:

data <<= 1;
data += 1;

Doet wel goeie dingen btw.

[ Voor 71% gewijzigd door Graaf op 19-12-2006 21:25 ]

[farlane]

C:

static uint32_t sq = 0;

sq = ( sq << 1 ) | bit;

if( sq == sequence )
 synced = true;

etc.

natuurlijk hoef je niet te controleren of er 32 bits gelezen zijn want het eerste bit kan ooit 1 zijn als dat niet zo is

Waarom gebruik je + als je duidelijk aan het bitpielen bent? Je wilt niet iets optellen je wilt een buffer schuiven en aanvullen.

Met alle respect ioish maar ik krijg geen positief gevoel bij die code van jou. Je initialiseert je variabelen niet, je gebruikt een int en je algehele structuur krijgt nu al iets van een chaos.
Maar misschien ben ik het ....

Oh ja, en je suggereert een blocking constructie terwijl dit in een interrupt routine zou moeten draaien


[edit]
maak zelf stomme fout

[ Voor 54% gewijzigd door farlane op 19-12-2006 23:38 ]

[Graaf]

So far So good.

Op dit moment herkend ie de sync sequence ( sync1 ): 0x870CA6C6AAAA78F3
Maar. eigenlijk zou het anders moeten.

Hij moet de sync1 herkennen op de middelste 2 words, en de buitenste 2 moeten bijelkaar "opgeteld" 0xFFFF vormen.

ik vond weer wat info

code:

    // 64-bit FLEX sync code:
    // AAAA:BBBBBBBB:CCCC
    //
    // Where BBBBBBBB is always 0xA6C6AAAA
    // and AAAA^CCCC is 0xFFFF

    // Specific values of AAAA determine what bps and encoding the
    // packet is beyond the frame information word

[farlane]

Als je die woorden zo kunt herkennen voldoet het toch aan die voorwaarde? Dat hoef je niet extra te controleren

[Graaf]

Ok.
Volgens mij is de sync1 altijd het zelfde in dit geval. p2000 zal wel altijd op 1600bps gaan.

Nu verder uitvogelen hoelang een frame is, om zo aan het einde van een frame de sync setter weer op false te zetten. En het frame te decoden. Error correctie e.d.

Je zegt over de FI dat dat bestaat uit 144 64bits ? Waar haal je die info vandaan?

[Verwijderd]

farlane schreef op dinsdag 19 december 2006 @ 21:27:

natuurlijk hoef je niet te controleren of er 32 bits gelezen zijn want het eerste bit kan ooit 1 zijn als dat niet zo is

erm...wat je daarmee bedoeld weet ik niet, maar goed. Bij het detecteren van de sync waarde tel ik dan dan ook niet tot 32. Maar daarna ga ik er van uit dat je de gelezen waardes nog steeds als bits aangeleverd krijgt. Lijkt me wel handig om bij te houden,nadat je de sync sequence gevonden hebt, hoever je bent met het lezen van een byte cq. word. Of is de meeste significante bit altijd 1 in dit geval?

Waarom gebruik je + als je duidelijk aan het bitpielen bent? Je wilt niet iets optellen je wilt een buffer schuiven en aanvullen.

Maakt in dit geval niets uit gezien bitwise OR of + hetzelfde opleverd in het geval van waarden die liggen in het beriek 2 tot de macht n. (wat in dit geval dus zo is).

Met alle respect ioish maar ik krijg geen positief gevoel bij die code van jou. Je initialiseert je variabelen niet, je gebruikt een int en je algehele structuur krijgt nu al iets van een chaos.
Maar misschien ben ik het ....

resultaat is de enige die geintialiseerd had moeten worden. De anderen zijn of geintialiseerd of dat wordt gedaan door een functie alvorens deze te gebruiken. Een beetje flauw dus, want de code is puur om een idee te geven, net zoals het gebruik van usigned int ipv uint32_t. Wat bedoel je trouwens met chaos in dit geval? twee korte functies die iets heel bassaals uitvoeren met commentaar erbij lijkt me nou niet bepaald chaotisch...

Oh ja, en je suggereert een blocking constructie terwijl dit in een interrupt routine zou moeten draaien

Da's dan wel weer waar, ik was vergeten dat er gewerkt werd met interupts.

[farlane]

Verwijderd schreef op woensdag 20 december 2006 @ 14:24:
Bij het detecteren van de sync waarde tel ik dan dan ook niet tot 32.

Je hebt gelijk, ik had ff niet opgelet dat het bij de sync niet het geval was. Mijn excuses.

Maakt in dit geval niets uit gezien bitwise OR of + hetzelfde opleverd in het geval van waarden die liggen in het beriek 2 tot de macht n. (wat in dit geval dus zo is).

Het gaat er niet om dat het hetzelfde doet, waar ik op doelde is dat je code (voor mij iig) moeilijker te lezen is als je er niet staat wat je aan het doen bent. ( Namenlijk bitjes schuiven en ORen )
Iha zijn er legio methoden om hetzelfde te bereiken maar dat wil niet zeggen dat elke methode even duidelijk is.

Wat bedoel je trouwens met chaos in dit geval? twee korte functies die iets heel bassaals uitvoeren met commentaar erbij lijkt me nou niet bepaald chaotisch...

Nee dat klopt. En toch krijg ik bij het zien van deze 2 functies het gevoel dat het hele project bij elkaar een grote chaos zal zijn. Kan het niet goed uitleggen. Volgens mij komt dat ook doordat het twee functies zijn die er vrijwel hetzelfde uitzien maar dus wel degelijk iets anders doen. Kweenie, trek het je niet teveel aan misschien hallucineer ik alleen maar.

[Verwijderd]

farlane schreef op donderdag 21 december 2006 @ 00:49:

Het gaat er niet om dat het hetzelfde doet, waar ik op doelde is dat je code (voor mij iig) moeilijker te lezen is als je er niet staat wat je aan het doen bent. ( Namenlijk bitjes schuiven en ORen )
Iha zijn er legio methoden om hetzelfde te bereiken maar dat wil niet zeggen dat elke methode even duidelijk is.

grappig dat je dat juist zegt, ik probeer juist zoveel mogelijk de bitpiel operators te vermijden omdat jammergenoeg veel programeurs en engineers daar weinig kaas van gegeten hebben. Ik ben het met je eens dat | mooier is en ik snap het ook zelf wel (vind het zelfs een van de leukste dingen van programmeren), maar als ik daarna tich keer moet gaan uitleggen wat |, &, ^ etc is, dan gebruik ik het liever niet. Vandaar het gebruik van plus. Aan de andere kant moet je inderdaad maar net weten dat + in dit geval precies hetzelfde doet.

Nee dat klopt. En toch krijg ik bij het zien van deze 2 functies het gevoel dat het hele project bij elkaar een grote chaos zal zijn. Kan het niet goed uitleggen. Volgens mij komt dat ook doordat het twee functies zijn die er vrijwel hetzelfde uitzien maar dus wel degelijk iets anders doen. Kweenie, trek het je niet teveel aan misschien hallucineer ik alleen maar.

[farlane]

Verwijderd schreef op donderdag 21 december 2006 @ 16:46:
grappig dat je dat juist zegt, ik probeer juist zoveel mogelijk de bitpiel operators te vermijden omdat jammergenoeg veel programeurs en engineers daar weinig kaas van gegeten hebben.

Dan horen ze imho:
A Uit te zoeken wat die operators doen ( volgens mij hoort iedereen die een beetje basiskennis heeft van dit soort dingen it te weten, al was het alleen maar om het verschil met de booleanse operators te kennen )
B Te vragen wat ze doen
C Dit soort software niet te schrijven
D Geen software te schrijven
E C & D Zijn beide goed

[ATS]

ik probeer juist zoveel mogelijk de bitpiel operators te vermijden omdat jammergenoeg veel programeurs en engineers daar weinig kaas van gegeten hebben. Ik ben het met je eens dat | mooier is en ik snap het ook zelf wel (vind het zelfs een van de leukste dingen van programmeren), maar als ik daarna tich keer moet gaan uitleggen wat |, &, ^ etc is, dan gebruik ik het liever niet. Vandaar het gebruik van plus. Aan de andere kant moet je inderdaad maar net weten dat + in dit geval precies hetzelfde doet.

Mensen die | niet begrijpen, begrijpen << al helemaal niet lijkt me...

[Graaf]

Terug naar de materie

Ik heb de module nou geladen, en als er een sync1 gevonden wordt, vang ik de volgende 64 bitjes eventjes op in een buffer om deze te outputten.

Hieronder een copy/paste van de log. Je ziet hier de 64 bits direct na de sync1 ( welke het begin van een bericht aangeeft )

code:

Dec 19 23:23:14 ubuntu kernel: [ 4400.839994] SYNC1 FOUND!
Dec 19 23:23:14 ubuntu kernel: [ 4400.880656] P2000 - ac9c9fa8fc8e2893
Dec 19 23:23:15 ubuntu kernel: [ 4402.714256] SYNC1 FOUND!
Dec 19 23:23:15 ubuntu kernel: [ 4402.754874] P2000 - ac9cdfc8fd08a893
Dec 19 23:23:17 ubuntu kernel: [ 4404.588440] SYNC1 FOUND!
Dec 19 23:23:17 ubuntu kernel: [ 4404.628970] P2000 - ac9cbf88fcbaa893
Dec 19 23:23:42 ubuntu kernel: [ 4428.952821] SYNC1 FOUND!
Dec 19 23:23:42 ubuntu kernel: [ 4428.993420] P2000 - ac9cd3effcf12893
Dec 19 23:24:08 ubuntu kernel: [ 4455.191422] SYNC1 FOUND!
Dec 19 23:24:08 ubuntu kernel: [ 4455.231955] P2000 - ac9c93dbfc0fa893
Dec 19 23:24:10 ubuntu kernel: [ 4457.065516] SYNC1 FOUND!
Dec 19 23:24:10 ubuntu kernel: [ 4457.106115] P2000 - ac9cd39bfc672893
Dec 19 23:24:12 ubuntu kernel: [ 4458.939774] SYNC1 FOUND!
Dec 19 23:24:12 ubuntu kernel: [ 4458.980394] P2000 - ac9cb3ebfccc2893
Dec 19 23:24:14 ubuntu kernel: [ 4460.813933] SYNC1 FOUND!
Dec 19 23:24:14 ubuntu kernel: [ 4460.854567] P2000 - ac9cf3abfca4a893
Dec 19 23:24:15 ubuntu kernel: [ 4462.688062] SYNC1 FOUND!
Dec 19 23:24:16 ubuntu kernel: [ 4462.728693] P2000 - ac9c8bcbffd72893
Dec 19 23:24:17 ubuntu kernel: [ 4464.562248] SYNC1 FOUND!
Dec 19 23:24:17 ubuntu kernel: [ 4464.602862] P2000 - ac9ccb8bffbfa893
Dec 19 23:25:04 ubuntu kernel: [ 4511.416922] SYNC1 FOUND!
Dec 19 23:25:04 ubuntu kernel: [ 4511.457487] P2000 - ac9c93f9ff7c2893
Dec 19 23:25:40 ubuntu kernel: [ 4547.026373] SYNC1 FOUND!
Dec 19 23:25:40 ubuntu kernel: [ 4547.067032] P2000 - ac9c8b9efc552893

Herkenning?

Ja de eerste 4 bytes zijn altijd AC9C
( en de laatste 3 bytes lijken wel altijd 893 te zijn )

edit:
Zo anders loopt m'n bak eventjes ver achter met de tijd
offset 168011.344584 sec

--

Ik moet toch wel gaan pielen op de sync1 0x870CA6C6AAAA78F3.
Dat ik dus de middelste 2 words, die altijd A6C6 AAAA zijn, herken en de buitenste 2 bijelkaar plak en 0xFFFF moet zijn dan.

Want ik merk dat er soms wat berichten niet herkend worden als ik op de volledige sync1 check.

[ Voor 8% gewijzigd door Graaf op 21-12-2006 22:21 ]

[farlane]

Volgens de thesis:

sync1: 32 bits + 16 dotting bits + 32 bits, uniek
sync1 + frameinfo: Altijd op1600bps, 90ms lang ( 144 bits )
frameinfo: ?
sync2: 25ms lang ( 40bits op 1600bps)

Als dat bij jouw niet klopt, moet je erachter zien te komen of je decodering misschien niet klopt of dat de protocolomschrijving niet klopt
Probeer eens een heel block te decoderen met de decodering die je nu hebt en kijk of er zinnige informatie uit te halen is.
Klopt de data die erin staat dan moet je het controleren van de header (syncs enzo ) pragmatisch aanpakken denk ik. Controleer voor zover je weet dat het goed is. Das een beetje het nadeel van reverse engineeren

[Graaf]

Weer een stukje log:

code:

Dec 22 11:03:45 ubuntu kernel: [51199.209118] P2000 - sync1 found: 870ca6c6aaaa78f3
Dec 22 11:03:45 ubuntu kernel: [51199.209143] P2000 - flex_modes[0]: 870c78f3 - 1600 - 2
Dec 22 11:03:45 ubuntu kernel: [51199.249763] P2000 - first 64bits: ac9cb780fcb72893
Dec 22 11:03:45 ubuntu kernel: [51199.288510] P2000 - next  64bits: dd76c22aaaeaaaea
Dec 22 11:03:45 ubuntu kernel: [51199.328506] P2000 - next  64bits: eaeaeaeaeaaaeaea
Dec 22 11:03:47 ubuntu kernel: [51201.083337] P2000 - sync1 found: 870ca6c6aaaa78f3
Dec 22 11:03:47 ubuntu kernel: [51201.083360] P2000 - flex_modes[0]: 870c78f3 - 1600 - 2
Dec 22 11:03:47 ubuntu kernel: [51201.123889] P2000 - first 64bits: ac9cc3fffceba893
Dec 22 11:03:47 ubuntu kernel: [51201.162702] P2000 - next  64bits: dd76c22aaaeaaaea
Dec 22 11:03:47 ubuntu kernel: [51201.202696] P2000 - next  64bits: eaeaeaeaeaaaeaea
Dec 22 11:03:49 ubuntu kernel: [51202.957513] P2000 - sync1 found: 870ca6c6aaaa78f3
Dec 22 11:03:49 ubuntu kernel: [51202.957535] P2000 - flex_modes[0]: 870c78f3 - 1600 - 2
Dec 22 11:03:49 ubuntu kernel: [51202.998049] P2000 - first 64bits: ac9ca3bffd59a893
Dec 22 11:03:49 ubuntu kernel: [51203.037427] P2000 - next  64bits: dd76c26b84540fd0
Dec 22 11:03:49 ubuntu kernel: [51203.078082] P2000 - next  64bits: 5fc3f7f7f78fc003

Dit is 1 alarmering bestaande uit 3 berichten dus.

[farlane]

Is er van de data die erin staat ook nog wat te maken?

[Graaf]

farlane schreef op vrijdag 22 december 2006 @ 14:56:
Is er van de data die erin staat ook nog wat te maken?

Geen flauw idee nog.
Komende dagen eerst maar eens uitvogelen wat ik met deze data moet doen.
Ik wil nou eerst de frame info proberen te decoden, zodat ik weet welke frames bij elkaar horen.

[Graaf]

De afgelopen weken heb ik nog beetje zitten rommelen, en veel data zitten bekijken.
Maar ik heb zo'n vermoeden dat het me echt niet gaat lukken.

Ik begrijp er werkelijk niks van wat en hoe ik verder moet na een sync1 detectie.
Ik heb wat stukken source uit andere projecten waar ze flex/pocsag via geluidskaart decoden, maar 't helpt me er niet bij.

Mocht er interesse zijn voor de sourcecode wat in tot nu toe geprutst heb, laat het maar horen.

Ik kom er niet meer uit. helaas

[farlane]

Als je een sync1 hebt gedecodeerd moet je de andere velden ook decoderen

Seriously,

Heb niet de tijd om het protocol helemaal te gaan analyzeren, maar je probeert met de informatie die je hebt het hele bericht te pakken te krijgen.

Pas daarna decodeer je de data in het bericht ( de datavelden ) en probeer je van de data wat te maken.

Het klinkt allemaal wat abstract, maar een hele simpele manier zou kunnen zijn om als je een sync1 hebt, alle data te decoderen to je weer een sync1 krijgt. Daarna zou je kunnen gaan bekijken of de data die tusen die syncs zit kunt rijmen met de ietwat beperkte protocol info die je hebt.

Het belangrijkste is echter om te verifieren dat alle bytes correct worden gedecodeerd, dus dat je niet naar bogus info zit te kijken. ( Het rotte van bv een timing probleem is dat het mogelijk is dat de eerste 32 bytes wel correct worden gedecodeerd, maar de rest niet omdat de timing langzaam scheef gaat lopen )