Rockbox mail archiveSubject: Re: new thread about remote control with display
Re: new thread about remote control with display
From: George Styles <george_at_ripnet.co.uk>
Date: Tue, 8 Oct 2002 10:22:10 +0100
That all sounds very interesting. You obviously know more than me about
If we can get this working, with an open protocol, it could be used for
things other that the Rockbox (for example, remote controlling palm-tops,
Linux boxes plugged into your Hi-Fi as MP3 jukeboxes etc).
That would increase the possible 'market' for such a device, and drive down
costs - i imagine it would cost quite a lot to make (say) 300 of them for
interested Archos users...
nice work :)
----- Original Message -----
From: "Andreas Zwirtes" <zwirtes_at_gmx.de>
Sent: Tuesday, October 08, 2002 1:34 AM
Subject: new thread about remote control with display
> Hi all!
> Just read a thread about LCD and remote, that was not too long ago. I
> have some thoughts to add from a pro automotive systems developer. This
> is very technical stuff and may be hard to read. But at least i think it
> is worth the time. So let's start with some basic stuff.
> You should not connect the jukebox to a PC parallel port, since theese
> are parallel, not serial. The PC usually has serial ports available, so
> make use of them. This will make life much easier on the Linux/Windows
> side. It takes few minutes to get a serial communication program running
> in VB, but maybe several days to mess around with hardware drivers and
> timing on the parallel port. Once there is a defined serial protocol, i
> will find the time to implement it on windows. The parallel port already
> burnt it's outline in my calendar and i won't touch it any more except
> for simple tasks like programming controllers..
> A Controller that handles UART data on one pin is not necessary. The
> automotive industry shows us how to do it. They use an interface that is
> called "K-Line". It implements bidirectional communication with one
> line. The tricky part is: Both sides have to stick to a given protocol,
> that avoids data collision. I can contribute on that issue, if needed.
> More on that issue below. There are sophisticated protocols around, that
> also allow interruption of one sender by another with higher priority
> without loosing data. The suggestion of Andreas Stemmer points the
> right way. It would be easy for both controller and rockbox if the
> controller frequently asks for data. The rockbox wouldn't spend much
> time on the commnuication, because the most complicated part
> (oversampling and aligning the serial data) is done by the integrated
> UART. The suggested solution is very similar to automotive K-Line
> withount priority interruption.
> It is ok to send data via a time dependent routine. But if we do this
> (which seems to be necessary since UART TX of the jukebox is not
> available) the remote should have a hardware UART, since theese do
> oversampling and jitter/timing corrections. Atmel have sophisticated and
> small low power (3.3V) parts with UARTs.
> Electrical protection is not very complicated if controller ports are
> used on both receive-sides. The ports of the Atmel AVR parts for example
> are ESD protected and have a very high resistance. Also the SH1 ports
> have a very high internal resistance. So a simple resistor and a small
> cpacitor (!) is enough to protect both devices from current overdrive
> even against shorts to VCC or GND. Although short circuits are a problem
> with the SH1 without an internal resistor. Chaotic communication with
> the original firmware is not a problem with the above mentioned
> protection. Don't think about drawing power from the communication line,
> unless you already have experience with it. In most cases discharged
> capacitors result in heavy communication problems and thus - lots of
> communication. This - on the other side - prevents the power capacitor
> from charging properly. Also such circuits will result in a badly edged
> signal and cause the controller to draw much power. This is common to
> all digial CMOS circuits that have to deal with slow rising signals.
> Battery drain for frequent polls of the remote is not a problem, if a
> UART is used. Frequent LCD updates will draw more power. Don't push the
> communication speed for transmitting command too fast. This will
> increase software load on the jukebox and power requirements of the
> controller. 1200 up to 2400 baud is enough, seriously. Also it is not
> necessary to "introduce" the remote/display to the jukebox, because it'l
> ask the jukebox for display data. The protocol should enable the rockbox
> software to distinguish between original and new remote. With a pretty
> well defined protocol it's absolutely no problem to decide if a standard
> or "rockbox-type" remote is connected.There is no need to detect spikes
> or something. The jukebox could send a wakeup (that's a short push to
> ground) to the remote if there is no communication for a given (timeout)
> time. Well, certainly it's necessary to analyze the original remote's
> protocol and schematics to develop a suitable protocol. That sort of the
> before mentioned wakeup is common "language" for most automotive
> sensors, that the remote control is very similar to With this
> implemented, the remote can also shut down safely without consuming
> power or listen to repetitive communication. It will just wake up, if
> there is a need to (AVRs and most of the other controllers can do that).
> The "plug out" situation will be detected by missing answers from
> rockbox. No need for a shutdown command.
> Just to answer the questions regarding power: It is absolutely necessary
> to put the controller in total halt mode. A very good AVR software
> design will draw less than one microamp in power down mode. And that is
> the only choice when talking about battery life and small CR2032 Lithium
> batteries to keep the device small and handy. We design door lock remote
> controllers for cars, so i know what i'm talking about. This is also
> possible with a PIC, but they will draw lots of power while trying to do
> a UART emulation. I also wonder - while talking about power - what kind
> of display are you talking about? Standard LCDs with build in controller
> draw more power than one of theese little lithium batteries are able to
> provide. Connecting a custom LCD directly to the controller (which is
> the only alternative i can imagine at the moment) is only possible with
> special controllers. Then we are talking about Texas Instruments. This
> problem should be solved before implementing any software, because it
> has a high impact on software structure, timing and maybe also on the
> Generally it's good advice to have some spare bits and a checksum/size
> information (called "framing" in automotive) in all transmissions to
> differentiate newer versions of remotes in the future and to ensure
> correct information. It's annoying to see a fried up display due to
> communication problems. Also timeouts should be well thought and
> defined. It's better to think about that beforehand, trust me. Could
> help on that, maybe with a communication specification.
> I don't think that it is possible to do implementations of - for example
> Sony - vendor specific propietary protocols for displaying information
> on commercial (car-) hifi devices. Just for one reason: There are too
> many of them and most are undocumented. Surely it's better to develop a
> transparent (documented and easy to understand) protocol. Anybody can
> port it to his own device, if he wants to. In one part - that goes to
> Andreas Stemmer - i disagree with you. I think, that it is not much of a
> problem to get the hardware working. The tricky part always is the
> software. btw: respect to all rockbox developers.
> Just dreaming: What about a transparent protocol and a small interface
> hardware to talk to a ready made consumer remote? Sounds like a flexible
> solution that could fit to various protocols and interfaces....
> Hope i didn't stress you too much!
> Wasn't it Dire Straits who used to sing about "too much information"? ;)
> Andreas Zwirtes aka radhard
Received on 2002-10-08