[Rxtx] Latency Woes

[Curtis Hacker]

So I looked over the Tunerpro log again today.. is it me or does it 
appear to be reusing values ?

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/e5b21f91/attachment-0528.htm>