TI-H: Re: IR Link Status (was: expensive remote control)

[Prev][Next][Index][Thread]

TI-H: Re: IR Link Status (was: expensive remote control)


Osma Suominen wrote
> 
> Sami Khawam wrote:
> 
> > -Another possibility is the change the MChat and
> >  make it compatible with the link.
> 
> If it is possible, without deviating from the I2C specifications, then I'll
> do it. But I think that in this case, the hardware should adapt to the
> software's needs in every way, except for the speed, because it's hard to
> make a fast IR link.


What I ment was to change the protocol used by MChat so that the
circumstance that generate the error (that was described before) will 
never happen. For example,the TI protocol does work with the Line State 
mode, the I2C protocol doesn't.

 
> > -And the other possibility is the change MChat so
> >  that it won't use the I2C protocol, but the TI protocol
> >  , since this protocol is fully working.
> 
> What's the point in that? MChat is a multiuser chat program and uses I2C
> because it allows many calcs to be connected. The TI protocol is restricted
> to 2 calcs and there are TI protocol chat programs other than MChat.
 

An IR signal sent in the TI protocol can be recieved by multiple
calcs, not only 2.


> How about this: Make the PIC distinguish between a low state received from
> the calc, and a low state received by IR. It should only send "Hey this pin
> is low" messages by IR if the calc is pulling the pin low, not if the low
> state originated somewhere else.
> 
> This means that only the calc that actually pulled the pin low will have
> its PIC send the state over IR. With your example, it would look like this:
> 
> (with both pins high)
> 
> 1. Calc 1 pulls the pin low.
> 
> 2. PIC 1 sees the low state and knows it came from Calc 1 and not by IR. It
> therefore sends a low state message by IR.
> 
> 3. PIC 2 sees the low state message and pulls the line of Calc 2 low, but
> the PIC memorizes that the signal came in by IR and doesn't respond with
> anything.
> 
> 4. After a second, PIC 1 resends the low state. PIC 2 doesn't do anything,
> because it knows the original signal came in by IR.
> 
> 5. Calc 1 releases its data pin (it was never pulled down by PIC 1). PIC 1
> sees the change and transmits a high state message by IR.

  ^
  |
Here is the problem.

> 
> 6. PIC 2 releases its data pin when it sees the high state message.
> 
> However, there's still one more problem...Calc 1 and PIC 1 will never know
> if Calc 2 held the pin low when Calc 1 released it. This normally doesn't
> matter because it was pulled down anyway and when PIC 1 sensed and
> announced the change, PIC 2 would inform it about that the line is still
> held down, this time by Calc 2. This delay can be sufficient for Calc 1 to
> think that its data line is now high, even though it should still be low.
> If the IR link was fast enough this will never happen, but I doubt the IR
> link can respond in about 5 microseconds (the tightest possible link port
> reading loop).


The problem that is here solved by rembering if
the signal came from IR or not, was already solved (see
the last message) by the fact that the PIC check if the
pin is high so that it can output a low.

The essetial problem hasn't been solved here: it is
in step 5: when calc 1 relases the line it will read
a high signal an not a low.

 
> One possibility of solving this is using a "three-state" approach (no, not
> the one with a high impedance state), where the PIC uses a low signal level
> of around 1.5 - 2.5 volts instead of the standard TTL levels. My TI-85
> recognizes voltage levels of <2.7 V as a low state, but I think the low
> state it produces itself has a much lower voltage. Thus, the PIC could know,
> with some external components, if the calc was actually pulling the pin low,
> even if the PIC itself was already pulling it "low" (for the calc). I admit
> this is dirty, has anyone got a better approach?


By adding one transistor to each line the problem can
be very easily overcome. But before making this, we
have to see if we could solve it by software.


-- 
Sami Khawam
sKhawam@bigfoot.com
a9501901@unet.univie.ac.at
http://unet.univie.ac.at/~a9501901
Follow-Ups: References: