How can I handle stick parity in VB.NET 2005 without built-in functions?

  • Thread starter Thread starter ionlylooklazy
  • Start date Start date
  • Tags Tags
    Parity
AI Thread Summary
The discussion centers on handling stick parity in VB.NET 2005 for RS232 communication, where the first byte must have its parity bit set to one and subsequent bytes set to zero. Users are experiencing parity errors due to the lack of built-in support for stick parity in the SerialPort class, leading to difficulties in processing data. Suggestions include setting the parity to none and creating a custom function to manage stick parity manually. There is also mention of using Windows API functions to potentially address the issue. The key takeaway is that a custom solution may be necessary to properly format and send data without interference from the SerialPort class.
ionlylooklazy
Messages
30
Reaction score
0
Hello all,

Im trying to communicate with a RS232 device utilizing stick parity. This is defined as the first byte of a packet having its parity bit set to one, while all proceeding bytes have their parity bit set to 0. This was meant to be used to determine the start of a new packet.

However, there is no built in function to handle stick parity and I am generating all sorts of parity errors, which makes processing the data dificult.

AFAIK, when a parity error is detected, it inserts a specified value into the input stream, but when I read the stream the byte that was supposed to have generated the parity error still appears. is there anyway to disable this insertion?

I tried setting up an error event that would read the inserted byte out of the stream , but sometimes two or more bytes are inserted, and it seems to only remove one. here is my error event

Code:
Private Sub Data_Error(ByVal sender As System.Object, ByVal e As System.IO.Ports.SerialErrorReceivedEventArgs) Handles SerialPort.ErrorReceived
    
    Dim x As Integer
      
    x = SerialPort.ReadByte

    End Sub


I also tried setting the parity to space (parity bit always = 0). This way, I thought that when a parity error is generated, that would signal the start of a new packet, but strangely the error does not always occur.


Does any have any experience with stick parity, or have any suggestions?

Thanks,
IOLL
 
Technology news on Phys.org
Take a look at http://www.freevbcode.com/ShowCode.asp?ID=4666. It uses api functions and probably has what you need.
 
hmm, I don't see anything I don't already have, but what exactly is an API function?


I don't have a problem setting up rs232 communication, its just using this strange parity scheme. if the parity was any of the standard values it would be npnp
 
I mean Windows API (formerly Win32 API) functions. Perhaps you already use them. I thought perhaps you could simply disable parity.
 
I assume you're using the class SerialPort which has an enumerated property "Parity":
Code:
SerialPort sp = new SerialPort();
sp.Parity = Parity.Even
sp.Parity = Parity.Mark
sp.Parity = Parity.None
sp.Parity = Parity.Odd
sp.Parity = Parity.Space
Mark parity being High Stick Parity where the parity bit is always set to 1, and space Parity where the parity bit is always set to 0.

So if i understand what's happening, you're communicating with an RS232 device which implements stick parity. Since the SerialPort class doesn't support the stick parity your device uses, the data you send using any of the available parities generates a parity error on the device. Is this what's happening?

I think that, using the SerialPort class, and assuming the Stick Parity your device uses is neither High nor Low stick parity, but some other format, then what you might have to do is set Parity to Parity.None. Then, you create your own StickParity function. This function receives a packet and processes the bytes according to your stick parity, which you then send to the device. Since Parity is set to Parity.None, the SerialPort class won't mess up your data and it should reach your device properly formatted.
 
Last edited:
Thread 'Is this public key encryption?'
I've tried to intuit public key encryption but never quite managed. But this seems to wrap it up in a bow. This seems to be a very elegant way of transmitting a message publicly that only the sender and receiver can decipher. Is this how PKE works? No, it cant be. In the above case, the requester knows the target's "secret" key - because they have his ID, and therefore knows his birthdate.
Back
Top