[Rxtx] Latency Woes

Tue Mar 8 12:33:35 MST 2011

Cable schematic: 
http://i1106.photobucket.com/albums/h377/vigilart/jackal%20logging%20set%20up/RS232SCHEMATIC.jpg

0.00268554 TunerPro.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 1952
0.00305178 TunerPro.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS
0.00297524 TunerPro.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS
0.00297384 TunerPro.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS 
StopBits: 1 Parity: NONE WordLength: 8
0.00000335 TunerPro.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 
BRK:0 EVT:0 XON:11 XOFF:13
0.00202540 TunerPro.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 
Replace:40 XonLimit:2048 XoffLimit:512
0.00000335 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS
0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 
RM:0 RC:2000 WM:0 WC:110
0.00000279 TunerPro.exe IOCTL_SERIAL_SET_QUEUE_SIZE VCP0 SUCCESS InSize: 
1024 OutSize: 512
0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS
0.00000279 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 
RM:0 RC:2000 WM:0 WC:110
0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS
0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 
RM:0 RC:400 WM:0 WC:300
0.00000559 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR
0.00000335 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR
0.00064980 TunerPro.exe IRP_MJ_WRITE VCP0 SUCCESS Length 1: .
0.01498738 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 1: .
0.00000363 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS
0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:200 
RM:0 RC:20 WM:0 WC:300
0.02042774 TunerPro.exe IRP_MJ_READ VCP0 TIMEOUT Length 0:

That is time on the left side. Now I'm with you on timing, it doesn't 
make a lot of sense, but that is how the logs come out. You can view the 
logs yourself.
Tunerpro log : http://www.ds-map.net/tunerpro_log.csv
My apps log : http://www.ds-map.net/my_log.csv
2nd app log : http://www.ds-map.net/my_log2.csv

All these logs, were done from the same car, same cable.

I have some older logs with some palm software, that was 13 sensors, and 
had a total 45-55ms between each set of 13.

More info about the car / ecu at http://mmcdlogger.sourceforge.net

Disassembly on the ecu:
[SS1:SS0] is baud rate divider, 00(16) 01(128) 10(1024) 11(4096), 
assuming basic clock of 2MHZ, we get 125000baud, 15625baud, 1953baud, 
488baud

In any event, I attempted a no sleep thread, that waited till 
in.available > 1, and it wasn't any faster than running the events. Then 
I tried a read write thread, that slept from 1ms to 30ms after it wrote 
(so it wouldn't read what it just wrote). And couldn't get it doing 
much. I wish I had more of an understanding of all of this, which is why 
I'm asking for help.

On 03/08/11 03:00, jfh at greenhousepc.com wrote:
> Curtis,
>
> At the risk of being told "No, they really say it can be done", 30 
> sensors is 30 * 3 character times (are you sure it's not a single byte 
> response?).  At 1953 baud, a single character time is 10 bits * (1 / 
> 1953) seconds, or 15.4ms as Bob pointed out.  30 * 15.4ms is 460ms, 
> and that assumes everything works perfectly, no turnaround times, etc.
>
> If you can come up with some other way to make the math work, I'd love 
> to hear it.
>
> Short and sweet -- just because TunerPro can talk to an ECM/ECU that 
> is running faster than 1953 baud doesn't mean your Mitsubishi (or 
> whatever car you've got that runs at 1953 baud) runs at that faster 
> baud rate.
>
> Also, are you sure your data cable is correct?  What cable are you 
> using?  What's the schematic?
> --
> Julie Haugh
> Senior Design Engineer
> greenHouse Computers, LLC // jfh at greenhousepc.com 
> <http://greenhousepc.com> // greenHousePC on Skype
>
>
>     -------- Original Message --------
>     Subject: Re: [Rxtx] Latency Woes
>     From: Curtis Hacker <hakcenter at gmail.com <mailto:hakcenter at gmail.com>>
>     Date: Tue, March 08, 2011 2:33 am
>     To: rxtx at qbang.org <mailto:rxtx at qbang.org>
>
>     I am going to try a couple things today and hopefully figure
>     something out.
>
>     Bob I don't want to pop your bubble, but a native application named
>     'TunerPro' can sample the same data, over 30 sensors, in less than
>     25ms.
>     I've exchanged some emails with the author and it is a native C,
>     polling, no events just timeouts.
>
>     Kusta thanks for the FTDI notice, I believe that is tunable,
>     however I
>     have a particular user using a Keyspan converter and verified
>     sampling
>     rate with 'TunerPro' and its just off the charts.
>
>     Chris thank you, I'll look into the queing.
>
>     On 03/07/11 23:02, Bob Jacobsen wrote:
>     > If you're transferring three bytes total at 1953 baud, it's going
>     to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to
>     wait 20msec to get the data back instead of 15.4 msec doesn't seem
>     to be as big a problem as you're making it sound.
>     >
>     > Bob
>     >
>     > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote:
>     >
>     >> I guess I'm gunna need some serious help with this then, because
>     of the scenario I'm stuck with.
>     >>
>     >> To communicate there is only 1 data line, rx/tx tied together
>     with a diode protecting the tx. No RTS/CTS handshaking nothing..
>     >>
>     >> So the ecu can't process the next byte of info, without you
>     pulling the 2 bytes back. I wish this was standard, but even the
>     baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard
>     spot with this..
>     >>
>     >> in.read(data <http://in.read%28data>, 0, 2);
>     >> ^ would the above wait till the timeout to read 2 bytes ? or
>     read 1 byte wait for the 2nd ? or just read the 1 ??
>     >>
>     >> On 03/07/11 18:50, jfh at greenhousepc.com
>     <mailto:jfh at greenhousepc.com> wrote:
>     >>> Curtis,
>     >>>
>     >>> No, I assume he means a real queue, not just "don't read all
>     the bytes at once." However, if you know you can process some
>     number of requests in some amount of time, allowing data to pile
>     up (receiver FIFO space permitting) can be a valid strategy.
>     Inserting gobs of Thread.yield() and notify() can help pep things
>     up as well.
>     >>> --
>     >>> Julie Haugh
>     >>> Senior Design Engineer
>     >>> greenHouse Computers, LLC // jfh at greenhousepc.com
>     <http://greenhousepc.com> // greenHousePC on Skype
>     _______________________________________________
>     Rxtx mailing list
>     Rxtx at qbang.org <mailto:Rxtx at qbang.org>
>     http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qbang.org/pipermail/rxtx/attachments/20110308/6e5eecaf/attachment-0495.htm>