[.NET 2] SerialPort klasse

[Verwijderd]

Devvende tweakerts,

Ik zit mezelf hier weer eens op te vreten van ergernis. Ik probleer te communiceren met een Nokia 3310 over MBUS (v1).

Dwz. dat ding hangt met een datakabel aan een PC en dat werkt. Ik heb dat gecontroleerd met een progsel dat verspreid wordt onder de naam LogoManager Classic en dat progje heb ik samen met mijn kabel ingesteld M-Bus communicatie en wat logotjes uitgewisseld.

Als ik Hyperterminal openknal en mezelf bel op die GSM komenen er als een gek pakketjes binnen en HyperTerminal verkracht al die data naar ASCII karakters (vreemd genoeg steeds de letter P maar dat zal wel aan de coderings instellingen liggen).

Nu het probleem; ik wil de functionaliteit van die GSM gebruiken in een .NET applicatie. En dit is de eerste keer dat ik dit in .NET doe, normaal doe ik dit soort dingen in VB6 met een MsComm object, nooit problemen mee gehad. Maar wat me opvalt is dat ondanks alle instellingen van mijn SerialPort instance goed staan (baudrate, stop bits, data bits, pariteit etc.) de DataRecieved event alleen reraised wordt als ik zelf data schrijf (die komt vanzelf in mijn input buffer terecht vanwege het M-BUS princiepe). De data die dus van de bus zelf komt raised dus geen event!

Overigens gaat alles op byte niveau, geen ASCII codering in die pakketjes zoals bijvoorbeeld bij AT compateble GSM's of andere zooi.

Erger dan dat is dat welke methode om mijn data te benaderen van SerialPort ik ook gebruik... Ik kan alleen de data eruit halen die ik er zelf ingestopt heb! Ook als ik een aparte threat maak en een while loop los laat op die read methodes krijg ik geen data!

Iemand een idee waarom ik geen data krijg? Morgen probeer ik in VB6 als ik de CD meeneem van mijn werk, weet 99% zeker dat ik daar wel kan communiceren gezien HyperTerminal gewoon data krijgt en de ervaring die ik heb met Rs232 en VB6.

Moet ik toch naar een oplossing waar de oude DLL gewrapped is voor .NET of doe ik gewoon iets fout?

[Woy]

Ik denk toch dat je wat verkeerd doet. Ik heb vaker met de SerialPort class gewerkt en heb daar niet echt problemen mee gehad.

Anders moet je mischien wat code laten zien.

[Verwijderd]

Nou ergens in een klasse hebben we een memberveld:

Visual Basic .NET:

Private WithEvents commNokia As Ports.SerialPort

Dan maken we ergens een instantie van die SerialPort klasse en openen we voor het gemak die poort:

Visual Basic .NET:

Me.commNokia = New Ports.SerialPort("COM1", 9600, IO.Ports.Parity.Odd, 8, IO.Ports.StopBits.One)
Me.commNokia.Open()

Nu is dit al genoeg om te weten dat er niks gebeurt:

Visual Basic .NET:

Private Sub commNokia_DataReceived(ByVal sender As Object, ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) Handles commNokia.DataReceived
      MsgBox("Aap!")
End Sub

Want als ik mezelf bel komt er geen aap uit de sub! Dat terwijl ik middels HyperTerminal eerder vastgesteld had dat de GSM altijd data over de bus stuurt als er een incoming call plaats vind.

Maar goed als we wat verder gaan dan:

Visual Basic .NET:

    Public Sub DoeIets()
        Dim byteBuffer(10) As Byte

        ' Wakker worden!
        byteBuffer(0) = &H0
        byteBuffer(1) = &HF8
        byteBuffer(2) = &H5
        byteBuffer(3) = &HE9
        byteBuffer(4) = &H0
        byteBuffer(5) = &H2
        byteBuffer(6) = &H1C
        byteBuffer(7) = &H0
        byteBuffer(8) = &H1C
        byteBuffer(9) = &H1
        byteBuffer(10) = &H17

        ' Pakket naar telefoon schrijven
        commNokia.Write(byteBuffer, 0, 11)
    End Sub

Dit is een wake-up pakketje.

Als ik dit wake-up pakketje verstuur krijg ik het terug. (Ervan uitgaande dat we in de data recieved event met de ReadExisting methode de Input buffer van onze poort verplaats hebben naar Me.strBuffer).

Stel ik doe zoiets:

Visual Basic .NET:

Dim strReturn As String = Nothing
Dim objEncoding As New ASCIIEncoding
Dim arrByteBuffer(Me.strBuffer.Length) As Byte
arrByteBuffer = objEncoding.GetBytes(Me.strBuffer)
For i As Integer = 0 To Me.strBuffer.Length - 1
strReturn &= "[" & arrByteBuffer(i).ToString & "] "
Next
MsgBox(strReturn)

Krijg ik netjes de bytes uit mijn pakket [xx] [xx] etc... Dus de data ik zelf verstuurd heb. (Wat normaal is bij M-BUS alleen krijg ik niks van de GSM).

Edit: door de pariteit worden de bytes die ik verstuur vervormd, tenzij ik geen pariteit gebruik. Maar dat doet er even niet toe voor het probleem.

[ Voor 3% gewijzigd door Verwijderd op 19-11-2007 22:11 ]

[farlane]

Dat je alles wat je zendt zelf ook leest kan heel goed kloppen als de GSM staat te echoen ( wat je in hyperterminal dus ook ziet ), dus zal dat ding dan ook events maken. Trek de kabel er eens uit en probeer het dan nog eens, als je nog steeds een echo krijgt ligt het aan .Net stuff.

Neemt niet weg dat ik met .Net bezig ben en mezelf al 2 weken aan het opvreten ben door die bagger IDE en nog meer bagger componenten ....


Btw ik zie dat je de poort opent met 8 databits terwijl je een ASCII encoding gebruikt .... das nie goed en zal misschien ook een reden zijn dat je characters scrambled verstuurt/binnenkrijgt.

[ Voor 46% gewijzigd door farlane op 19-11-2007 21:56 ]

[Guldan]

Ehm.. ik heb geen idee of het de oplossing is..maargoed ik had in C# hetzelfde probleem dit omdat ik de recievedBytesThreshold niet ingesteld had.. of iig te klein.. geen idee wat het precies was. Nadat ik dit aangepast had ging het bij mij iig goed. Ik kan echter niet zien of dat miste in je code.

[Verwijderd]

@Guldan: Ja heb die threshold niet aangepast in deze code. Ik heb er echter wel mee geexperimenteerd. Door hem bijvoorbeeld op 1 te zetten. Probleem is dat er geen vaste lengtes zijn voor de pakketjes. Er is een byte die aangeeft hoe lang ze zijn. Het heeft qua uitwerking weinig effect als ik de thershold verander. Maar ik zal eens proberen als ik een grotere threshold pak.

@farlane: voor de duidelijkheid. Er is maar 1 communicatie kanaal in MBUS, unidirectioneel, alles wat ik verstuur krijg ik automagisch in mijn eigen buffer terug, dat heeft mer de GSM zelf niets te maken. Ik gebruik helemaal geen codering... Die klasse doet de bytes als ASCII te coderen mits ik een methode gebruik die iets terug geeft als string... Ik zet ze gewoon terug om. M.a.w. als de SerialPort een byte met een hexadecimale waarde van 55 ontvangt dan geeft hij dat in een string terug als de letter "U". Die u doe ik in dat stukjes code met die encoding klasse weer omzetten naar een byte met waarde 55. Als ik ze gelijk als een array van bytes opvraag veranderd er niets aan het resultaat. Het is alleen efficiënter, maar voor dit voorbeeld want minder overzichtelijk.

Waar ik bang voor ben is dat de klasse ergens toch iets van interpretatie probeerd te doen over de data die de buffer binnen komt. Gezien de coderings property, de NullChar discard property en de endline property.... Ik moet echt de rauwe bytes uit mijn poort halen en ook gewoon byte arrays kunnen versturen zonder dat er iets aan toegevoegd of weggelaten wordt.

[ Voor 46% gewijzigd door Verwijderd op 19-11-2007 22:05 ]

[farlane]

Verwijderd schreef op maandag 19 november 2007 @ 21:58:
@farlane

Je hebt het telkens over ASCII encoding, en ook in je voorbeeld code gebruik je deze:

Visual Basic .NET:

Dim objEncoding As New ASCIIEncoding
Dim arrByteBuffer(Me.strBuffer.Length) As Byte
arrByteBuffer = objEncoding.GetBytes(Me.strBuffer)

ASCII encoding bestaat uit 7 bits characters, en ik zie in je voorbeeld dat je de poort opent met 8 databits, en ook een stuk waarbij je de code 0xF8 verstuurt. Dat klopt dus niet: Of je wilt 8 databits en je gebruikt een andere dan ASCII encoding Of je gebruikt 7 databits en ASCII encoding.

Probeer maar eens de code 0xF8 te encoen en weer decoden met de ASCII encoder, er zal geen 0xF8 uit komen.

Of het de oorzaak van je probleem is weet ik niet, maar het is zeker niet goed.


Wat betreft je unidirectionele ding, als je iets terugkrijgt in je buffer is het niet unidirectioneel. Ik vraag me wel af wat er dan voor zorgt dat je je eigen bericht terugkrijgt als dat niet de GSM is, heb je send en receive aan elkaar hangen ofzo?

[ Voor 12% gewijzigd door farlane op 20-11-2007 09:37 ]

[/\/\|)]

farlane schreef op maandag 19 november 2007 @ 21:42:
Neemt niet weg dat ik met .Net bezig ben en mezelf al 2 weken aan het opvreten ben door die bagger IDE en nog meer bagger componenten ....

Off-topic: wat een onzin. Je kennis van het framework is dus nog beneden peil.

[farlane]

/\/\|) schreef op dinsdag 20 november 2007 @ 09:58:
Off-topic: wat een onzin. Je kennis van het framework is dus nog beneden peil.

Ik had het niet over het framework, maar over de IDE en de componenten. Dat mijn kennis van het framework beneden peil is kan alsnog goed waar zijn.

[BM]

Visual Studio een bagger IDE vinden lijkt me wat overdreven, volgens mij staat deze toch bekend als 1 van de beste IDE's die momenteel te krijgen zijn.

Maar goed, das offtopic

[farlane]

BM schreef op dinsdag 20 november 2007 @ 10:19:
Visual Studio een bagger IDE vinden lijkt me wat overdreven, volgens mij staat deze toch bekend als 1 van de beste IDE's die momenteel te krijgen zijn.

Maar goed, das offtopic

Nja, misschien dat ik iets te ongeduldig ben maar VS2005 is met vlag en wimpel de meest trage IDE die ik in tijden heb gebruikt. Daarnaast ben ik tegen een bug aangelopen die de IDE vrolijk laat afstorten, en als je gaat zoeken dan zijn de problemen als sinds eind 2005 bekend bij MS. Er is er zelfs een die op schijnbaar willekeurige momenten optreedt waarvan ze zeggen dat deze 'by design' is.

http://connect.microsoft....ck.aspx?FeedbackID=106160

Let wel dit is een bug die Frans op 21-12-2005(!) gefiled heeft en die 17-04-2007(!!) geresolved is met de oplossing dat het in VS2008(!!!) gefixed is.

En zo zijn er nog een aantal dingen die het werken met VS2005 / Winforms echt een drama maken voor mij.

[/\/\|)]

Mijn referentiekader is Eclipse + Intelli J, VS.NET 2003/2005 + Resharper en Borland Delphi, waarbij ik Delphi veruit de instabielste IDE vind. De eerste twee ontlopen elkaar niet zo veel (elk heeft zijn eigen kuren).

[farlane]

Ik heb een ook paar ASP.Net dingen gedaan met VS2005; daar had ik lang niet zoveel problemen. ( Overigens, misschien is Eclipse wel de meeste trage IDE die ik gebruikt heb nu ik je post zie )
Ik ken de IDE van Delphi niet, maat het is natuurlijk een beetje flauw om als referentiekader een nog brakkere IDE te gebruiken.

Anyways, mijns inziens hebben de heren bij MS nog veel te verbeteren.

[ontopic]
Ben je al wat verder met je probleem beste TS?

[Woy]

Ik heb op het moment even geen code bij de hand. Ik weet wel dat ik altijd de BaseStream property gebruikte omdat ik gebruik maakte van Asyncrone reads en writes.

Mischien dat je even naar de basestream kijken of je daar wat verder mee komt.

[Verwijderd]

Ik heb in eerste instantie dat hele ASCII verhaal over boord gegooid. Het omzetten leverde idd verkeerde byte waardes op.

Ik haal nu een byte array terug en eindelijk klopt de data die ik terug krijg (zelf verstuurd heb).
De reden dat ik niks van de GSM terug kreeg was dat RTS kennelijk hoog moest zijn.... Iets dat volgens de MBUS protocol beschrijving (uit de gnokii source) duidelijk NIET moet.

Ik krijg nu wel data binnen! Enkel een hoop vreemde bytes. Als ik bv de GSM uitzet (handmatig) krijg ik heel vaak een 254 of 250 byte binnen... Ik moet me echter nog verder verdiepen in de protocol omschrijving, wat dat kan best aan mij liggen. Maar zoals het er nu uitziet werkt de SerialPort klasse zoals hij moet. Het lag dus aan RTS enable (hardware handshaking lijkt niet te werken en dat is ook niet de bedoeling).

Ik ga er vanavond na kijken dan deel ik mijn bevindingen mede.

Edit: farlane je hebt gelijk over ASCII had me vergist.

[ Voor 3% gewijzigd door Verwijderd op 20-11-2007 14:50 ]