From: Andreas Stemmer <Andreas.Stemmer_at_web.de>
Date: Sat, 5 Oct 2002 08:40:52 +0200

> > 1. The jukebox has to remember the type of remote which makes is a
> > little bit more complicated (not very much) for the rockbox guys.
>
> I dont think a bit setting is too much bother.

It's not only setting a bit, rockbox also has to query this bit
regularly
and behave depending on the bit of course. As I said, it's not a big
problem, but it could be more simple.

> > 2. How should the remote know when it is first plugged in? We would
> > need something like a connect-button on the remote or a remote that
> > recognizes if it doesn't get any screen updates.
>
> It can hold the transmit line high, and measure the OP after
> the contention resistor. This will be shorted to ground
> briefly when the remote is inserted, indicating an insertion.

This means, the remote will need much power, even if it is not plugged
in,
because it has to check the transmit line very often. Perhaps we should
make the remote wake up on any button press and then send the
"hi I'm here" message.

> To ensure this works properly, the "hello" message will
> probably need to be ACK'd from the Archos, to ensure that
> just touching the remote plug and shorting it with your fingers (or
> whatever) doesn't start it up.

I would normally plug in my remote when the jukebox is off.

> If we cant get this working
> reliably, the Archos could poll the port low for a couple of
> machine cycles every second. The chances of this messing with
> a normal remote are very low (most CMOS parts can handle full
> voltage scale contention as long as it is very short), and
> the remote could 'capture' this signal quite easily,
> recognising its insertion.

Again, lots of power consumption on the remote.

> Good question. But why on earth would they do this, and is
> it really a problem if they do? I guess we could make each
> message to the remote require a brief ACK level poll (a high
> or low pulse), so that the first message after the remote has
> been removed/replaced would time-out on the ACK, and then the
> 'LCD remote attached' bit can be cleared and everything is fine.

Good idea.
I'm not very experienced in such things, I have already programmed
a µ-controller (ATMEL) and can imagine what it can do, but I never
tested reliablity or power consumption or something like this.
Therefore I really appreciate your comments and suggestions.
I think both solutions are possible but still have the feeling,
that mine produces less complicated protocols and makes things
easier. As I posted before: let's try it... (but I'll need some time)

Andreas Stemmer
Received on 2002-10-05