serial port 2 stop bits mode

86 views
Skip to first unread message

Miguel Sanches

unread,
Oct 3, 2012, 10:41:44 PM10/3/12
to java...@googlegroups.com
Hello all

I use TC65 based terminal to read data from heat meter "Kamstrup Multical 601".
Heat meter uses serial port model 1200 bits per sec, 8 bit per char and 2 stop bits.
When I try to open serial port in java program with 2 stop bits it throws an exception telling me that 2 stop bits mode is not supported.
Despite heat meter serial setting, I try to open port in 1 stop bit mode, and it works! but...
I see randomly responses lost  from heat meter, about 60% of my requests. I suspect this happens cause of stop bits don't match.

So the question, how can I emulate 2 stop bits mode, or the is another way to deal with it?


Nikita Kapitonov

unread,
Oct 4, 2012, 5:51:29 AM10/4/12
to java...@googlegroups.com
Hello Miguel!

I think you can possible emulate longer stop bits by just sending your packets by one byte at a time, with a delay of 1 ms between each byte.

If you fail with it, the only way you have also is putting some kind of smart RS232-RS232 converter in between. I know there exists smart RS232-RS485 converters, that can convert also speeds and other parameters, so maybe there are also RS232-RS232 too. If not, you can use 2x smart RS232-RS485 converters =)


Best regards, | С уважением,
Nikita Kapitonov | Никита Капитонов
head of automation and monitoring
рук. отд. автоматики и мониторинга

Hydrologic Heating Systems
Отопительные системы «Гидролого»




2012/10/4 Miguel Sanches <rude....@gmail.com>


--
 
 

Miguel Sanches

unread,
Oct 4, 2012, 9:30:21 PM10/4/12
to java...@googlegroups.com
Thank you very much Nikita!

I set Thread.sleep(30) after each sent byte, and it begin to work much better.
Value of 30 ms choosen by an experiment, suggested by you value of 1 ms did not worked.

Nikita Kapitonov

unread,
Oct 5, 2012, 4:34:28 AM10/5/12
to java...@googlegroups.com
Glad to hear it works now!

Strange that 1ms delay didn't work, because as you said bitrate is 1200 bps, so 1 extra bit must be shorter than 1ms... Must be some hardware optimizations that make communication work differently, like a buffer in between. I think there is a way to flush the output buffer, so you don't have to wait so long each bit. I remember old C times, when you had to do flush() to make sure everything go to the right place right now.

It could look like

os.write((byte) a);
os.flush();
Thread.sleep(1);

Try it.

Nikita.


2012/10/5 Miguel Sanches <rude....@gmail.com>
Thank you very much Nikita!

I set Thread.sleep(30) after each sent byte, and it begin to work much better.
Value of 30 ms choosen by an experiment, suggested by you value of 1 ms did not worked.

--
 
 

em

unread,
Oct 5, 2012, 4:46:31 AM10/5/12
to java...@googlegroups.com
Hi,

as you wrote: "old C times" - new Java world is bit different ;)

I would rather not rely on the 'flush' method. It does not block till buffer is empty. 

BR makuda

--
 
 



Nikita Kapitonov

unread,
Oct 5, 2012, 5:32:26 AM10/5/12
to java...@googlegroups.com
The number of experts in this thread

[old bearded man sitting]

Is too damn high!



Glad to hear a skilled programmer's opinion =)
Though I got a quick google search and could not find a reference to it. Could you?

Nikita.



2012/10/5 em <mak...@gmail.com>
--
 
 

em

unread,
Oct 5, 2012, 5:54:00 AM10/5/12
to java...@googlegroups.com
I've participated once in a CWM java workshop in Warsaw and asked about flush method.
You can connect Oscilloscope to TX line and see that thread is far away from flush but data is still being transmitted - at least with TC65i/EGS5 1.1

BR makuda (not so old but with beard)

--
 
 



--
Pozdrawiam
       Jacek

Reply all
Reply to author
Forward
0 new messages