1

I have a problem with sending bytes through my comport. It sends a parity bit, although it is explicitly turned off (i need the byte without parity to communicate with some hardware). My code is really simple:

Process p = Runtime.getRuntime().exec("cmd.exe /c mode com1: baud=115200 parity=n data=8 stop=1 to=off xon=off rts=off dtr=off");
p.waitFor();
fp = new RandomAccessFile("COM1","rw");
fp.write((byte)0x21);

I have my oscillator connected to the port and whatever I do, there is one extra bit, which appears to be a parity bit. But as you can see, I disabled the parity via code, and also disabled it via my device manager. What i see on the oscillator is a : 0 0010 0001 11 (start and stop bit incuded). I can't figure out, where this parity or extra bit comes from... Anybody has an idea?

modmoto
  • 2,901
  • 7
  • 29
  • 54

2 Answers2

2

While that mode command one upon a time was intended to be used like you do and did work, I would be very skeptical to how much effort Microsoft has put into maintaining that kind of legacy support. My first step would be to open a command prompt and run

C:\>mode
C:\>rem The above command will display values to all configurable settings
C:\>mode com1: baud=115200 parity=n data=8 stop=1 to=off xon=off rts=off dtr=off
C:\>mode
C:\>rem Any visible changes compared to the first mode command?
C:\>echo U >> COM1
C:\>rem Check bits on oscilloscope

If this does not work like expected then I think you should just give up on the mode command. If all of that works, verify that the mode settings are not just properties within the shell running the mode command, e.g. after changing some parameters, run mode in a different shell to check that the parameters are changed there as well.

Additionally, according to documentation from Microsoft, the syntax for the baud=... parameter is not the numerical baud value but a two digit number mapped to a given baud rate (e.g. baud=96 -> 9600, see table in documentation). This site mentions an alternative syntax, MODE COM1:9600,N,8,1 which is more in line with what I remember being used, you could try that as well.

All of that failing, you could try using a java serial library. Rxtx is a commonly used, although not everybody likes it. This post recommends http://code.google.com/p/java-simple-serial-connector/ over rxtx. This post mentions http://code.google.com/p/jperipheral.

Community
  • 1
  • 1
hlovdal
  • 26,565
  • 10
  • 94
  • 165
  • thanks for the help, but I already tried a few things. I already tried the library you mentioned and it is a super weird one ;). I allready tried it with the console and realterm, where everything worked fine. It really seams to be a problem with the java function itself (see above) – modmoto Mar 24 '14 at 12:04
0

OK, I found a solution, but still do not know, why it does not work (and i don't intend to do so ;) )But as I want to send an array of bytes, it is the better solution anyway. If I use fp.write like this:

byte[] ba = {(byte)0xaa, (byte)0xaa};
fp.write(ba, 0, 2);

The parity bit does not get attached... What so ever. Maybe the library itself attaches a parity bit in the overloaded function or something else weird is happening :/

modmoto
  • 2,901
  • 7
  • 29
  • 54