Rockbox mail archiveSubject: Re: remote control
Re: remote control
From: Andreas Zwirtes <zwirtes_at_gmx.de>
Date: Fri, 11 Oct 2002 19:30:07 +0200
This is about hardware interfaces and protocol. last one first (my
Andrew and Andreas: Thank you!
I see we have a lot in common. And as Andrew said, it would make sense
to design the functional protocol (the upper next layer directly under
the application layer) in a way of a Q&A game. It is always good
behavior to answer requests. To pick up your example: request-> give me
power, answer-> Yes, next 100, 200...ms or No, can't do that). We should
set up a list of questions and answers of both, rockbox and remote. So
we'll use this protocol? That would make me very happy!
Andrew: Wish you nice holidays! Well, I don't think that we make any
decisions without hearing the opinons of everybody who is interested.
So, don't worry. Maybe i'll do some experimenting and we'll discuss some
issues. I also joined this discussion somewhat late. And please read the
last statements of who should be master or slave again. The Archos is
not able to detect various states and has to poll frequently, when no
remote is connected. That's not very good practive, especially when
original remotes are connected. They could loose frames and also might
be damaged. 3V (slightly pushed by resistor) would be the idle level.
One of both devices can put the line on low for >11 Bit times, what
would be recognized as Wakeup. 2V operation will definitively raise some
serious problems. I'd be glad, if you could check the port behaviour.
btw: We'll have to limit the duration of the power-pulse, because there
is no opportunity for the remote to communicate while in "charge-mode".
I'll try to start a design document.
some suggestions about interfaces:
The PC-Interface would only contain a few transistors and passive parts.
I don't think that anyone would buy an intelligent remote with buttons,
an expensive LCD and power management if he can build an interface for a
Although it makes sense to design the PC-Interface into the remote. So
everyone who buys (or builds) a remote already has the PC (or Sony or
whatever) interface. Theese can be optional parts on the PCB. So it is
possible to design one PCB (and one schematic of course) and choose the
functionality by different assemblies. There would be a list of
components, that are needed for different functionalities. We can make
use of large scale cost savings at least with the PCB (a good PCB would
be one of the most expensive parts). With a good design it should be
possible to build a very small remote through cutting of the unneeded
parts of the PCB. I know some pretty good layouters, after the
experimenting is done.
That should make escpecially Stuart very happy, because it is possible
to design a IR-Remote interface onto the standard remote PCB. Who
doesn't want to it simply does not apply the IR related parts. Yes, I
want to have IR, too! If we use Atmel AVR we have an in circuit
programmable processor, so that sofwtware updates only require a special
cable. PICs would require an additional voltage supply and are not very
good to program in circuit. Well, if we use mega-AVR we would be able to
upload a new software with the Archos, because mega-AVRs can do
something called "self-programming". That'd be cool! And Stuart: Neither
it is trivial to build a cable (think of the open-state), nor it is
trivial to write a new protocol. If it is, do it please! That would save
some people lots of work.
Andreas: There is no way to connect the Archos and a PC with two
resistors. That is only possible with a controller and 100% working
protocol firmware. But maybe the circuit for the PC fits in the D-SUB
housing. Although it is possible to connect the PC to the remote with a
level converter. MAXIM doeas a great job on this.
Received on 2002-10-11