[C++.NET] Robuuste communicatie met modem *

[Verwijderd]

Makkelijke/stabiele communicatie met GSM

Ik ben bezig om een modem (wavecom gsm module) aan te sturen om zo gesprekken af te handelen en de status van het modem uit te lezen.
Op dit moment probeer ik dat dmv AT commando's naar het modem te sturen door ze als bytes met writefile() (kernel32 api call) te sturen.

Met simpele dingen gaat dit goed, een atd0123456789; versturen etc gaat daarmee goed.
Maar ik wil meer bv om de halve seconde het bereik uit lezen en in de gaten houden of ik een belletje binnenkrijg.

Nu kan je dat weer oplossen door een lees thread te maken die continue de com poort uitleest en zo nu en dan een at+csq stuurt om het bereik op te vragen.

Maar mijn ervaring is dat het toch behoorlijk lastig is als je wat meer dingen wilt...

Ik heb al naar TAPI gekeken maar dit lijkt me zware overkill voor mijn toepassingen.

Mijn vraag is dus: is er een simpele manier om communicatie met modems te regelen?

De ontwikkelomgeving is .Net (met zijn slechte seriele poort ondersteuning) en c++.

[elevator]

Een handle naar een seriele poort kan je zelf wat tweaken met o.a. SetCommTimeouts() en SetupComm()

Voor het lezen zou ik een aparte thread maken die met behulp van WaitCommEvent() wacht op een receive (aan de hand van SetCommMask() gespecificeerd)

[farlane]

Waarom niet gewoon de poort pollen ? Het is niet elegant, maar het werkt altijd. Als je een kleine timeout meegeeft hoeft het niet eens lang te duren. Btw, als er een gesprek binnenlomt krijg je een RING bericht toch? ( eea beetje afhankelijk van je modem instellingen )

[Verwijderd]

elevator schreef op 15 september 2004 @ 23:13:
Een handle naar een seriele poort kan je zelf wat tweaken met o.a. SetCommTimeouts() en SetupComm()

Voor het lezen zou ik een aparte thread maken die met behulp van WaitCommEvent() wacht op een receive (aan de hand van SetCommMask() gespecificeerd)

Dat hebben we ook al geprobeerd. Het probleem is echter dat je bij een RING event van de modem niet meteen een CLI meekrijgt.
Je moet dus nog steeds de stream bekijken totdat je een +CLIP tegenkomt, die rippen en dan een ath sturen om op te hangen.

Je moet dus eigenlijk een aparte thread maken die telkens leest en zo nu en dan een AT commando stuurt. Als hij dan iets tegenkomt bv een CSQ (bereik) een CLIP of wat dan ook in een buffer schrijven en die buffer dan zo nu en dan weer uitlezen?
Lijkt me erg omslachtig..?

[elevator]

Het laatste wat jij beschrijft doe ik ongeveer zo in een programma en valt qua omslachtigheid nog wel mee

[LordLarry]

Of gebruik http://www.componentscience.net/Elements/TransPort/

[Verwijderd]

elevator schreef op 16 september 2004 @ 13:14:
Het laatste wat jij beschrijft doe ik ongeveer zo in een programma en valt qua omslachtigheid nog wel mee

Ook met een modem? Hoe bekijk jij bv dan de modemstatus? Door telkens CPAS naar de modem te sturen om de seconde ofzo?
Door de communicatie met de seriele poort is het lastig om bv (bijna) realtime status op te vragen (bellen/opgehangen/etc).

[farlane]

Verwijderd schreef op 17 september 2004 @ 08:38:
Door de communicatie met de seriele poort is het lastig om bv (bijna) realtime status op te vragen (bellen/opgehangen/etc).

Waarom is dat lastig ?

[Verwijderd]

farlane schreef op 17 september 2004 @ 09:11:
[...]


Waarom is dat lastig ?

Nou ik zou dan dus telkens at+cpas naar de com poort moeten schrijven.
En dan telkens de status uitlezen. Alleen gaat dat niet zo snel...

[elevator]

Verwijderd schreef op 17 september 2004 @ 08:38:
Ook met een modem? Hoe bekijk jij bv dan de modemstatus? Door telkens CPAS naar de modem te sturen om de seconde ofzo?
Door de communicatie met de seriele poort is het lastig om bv (bijna) realtime status op te vragen (bellen/opgehangen/etc).

Ik gebruik het enkel voor reguliere modems - en de AT+CPAS commando ken ik hierin niet, maar met een normaal modem is er (even uit het hoofd dus kan volledig fout zijn) connectie als DTR hoog is (iirc), de connectie verbroken als DTR laag is en je weet zelf wanneer je aan het bellen gaat?

[Verwijderd]

elevator schreef op 17 september 2004 @ 09:34:
[...]

Ik gebruik het enkel voor reguliere modems - en de AT+CPAS commando ken ik hierin niet, maar met een normaal modem is er (even uit het hoofd dus kan volledig fout zijn) connectie als DTR hoog is (iirc), de connectie verbroken als DTR laag is en je weet zelf wanneer je aan het bellen gaat?

Is dat het RLSD event toevallig?

[elevator]

Deze ja: MS_RLSD_ON

[farlane]

Verwijderd schreef op 17 september 2004 @ 09:21:
Nou ik zou dan dus telkens at+cpas naar de com poort moeten schrijven.
En dan telkens de status uitlezen. Alleen gaat dat niet zo snel...

Dat ligt niet aan de seriele poort, dat ligt aan je modem ( Een stringetje versturen en ontvangen op 38k4 gaat behoorlijk vlot imho ). En als je modem niet sneller wil, houdt al het andere ook op. ( Behalve de status van de modemlijnen, maar die geven je niet veel meer info dan 'het modem is aangesloten en kan karakters ontvangen, heeft karakters om te versturen' )
Anywayz, hoevaak wil je die status opvragen dan ? 10x per seconde ? Als je verder niets te doen hebt ? Voordat je iets wil doen ?
Naar mijn idee kun je met 1 maal per seconde de status vragen een behoorlijk eind komen. Commandos die je tussendoor wilt versturen kun je eerst in een queue plaatsen oid, en een event vuren vanuit je 'queuemanager' als het antwoord er is. Je moet zowieso vaak wachten op een antwoord omdat je modem bezig is met andere dingen ( detecteren SIM, inloggen gsm netwerk etc etc )

[ Voor 21% gewijzigd door farlane op 17-09-2004 11:49 ]

[Verwijderd]

elevator schreef op 17 september 2004 @ 09:59:
Deze ja: MS_RLSD_ON

Heb het nu zo gedaan:

code:

uint dwStoredFlags = EV_RING| EV_RLSD | EV_RXCHAR;
SetCommMask(hComm,dwStoredFlags);

if (WaitCommEvent(hComm,ref dwCommEvent,ref ovlCommPort))
{
if (dwCommEvent==EV_RING)
     Console.WriteLine("RING received.");

if (dwCommEvent==EV_RLSD)
     Console.WriteLine("Line status changed.");

Je zou dan denken dat als ik de lijn opneem dat ik een "Line status changed" in m'n console krijg. Maar dat gaat niet. Een RING event wordt wel goed opgemerkt..
De dwCommEvent is gewoon een 1 wat inhoudt dat hij een char ontvangt (ev_rxchar event dus ipv rlsd)..

[ Voor 11% gewijzigd door Verwijderd op 17-09-2004 15:13 ]