Rockbox mail archive
Subject: Re: new thread about remote control with display
From: Andreas Zwirtes (zwirtes_at_gmx.de)
A whole new bunch of information. I added conclusions, thoughts and
question to the reply, just to keep the context clear.
Also added a starting point for communiction.
Andrew Jamieson wrote:
>This is not necessarily what was suggested. Just bi-directional data
>transfer on the one pin from the Archos. The HW interface on the remote,
>and specific protocol is certainly up for grabs.
If the remote uses a controller with a UART, it should be ok to connect
the TX and RX with a resistor and connect the jukebox to the RX, because
this is always input and does not need short circuit protection. But
needs good signal quality. It won't be possible to use the receive
interrupt of the controller to wake it up, because that requires a
running oscillator. We could connect a third pin with "wake up on pin
change" functionality. In halt mode all pins could be switched to
"high-z". That would make it impossible to draw any current from the
The wake up on pin change, certainly on other pins, should also be used
to detect a keystroke. Otherwise it would not be possible to wake the
>Why? I still firmly belive that it would be simpler and more elegant to
>have the Archos send data when required to an LCD enabled remote. It is
>certainly simpler on the remote side to just take a data stream from the
>serial line and throw it onto the LCD (after unpacking the payload). I see
>they whole system as a master/slave arrangement, and I believe the Archos
>should be the master, not the remote.
That's easy. I hope you agree with me, that the jukebox should react as
fast as possible to keystrokes. A few years ago I've develloped a PWM
software for BMW that dimmed the interior lights. There has been a
noticeable delay due to the stroke/hold detection and debouncing
routine, although it was very fast. I had to change the software in a
way that it starts dimming even it doesn't know if it has to. If not,
the original values were restored. That story should just show the
importance of fast reaction to keystrokes /presses. It's what the
customer wanted me to do. When the archos is the communication master,
that would not be possible without high speed polling routines. On the
other side, most displays are not able to update very fast and in fact
the update is often a result from a keystroke. If the remote is master,
the first thing it will do after sending a keystroke is to ask for new
If we look a bit closer, we'll se another reason. Think of Remote and
Archos as persons. Most of the time, the Archos is singing songs for his
buddy. Now there is coming a third person to join the party. That's
Remote. Archos looks at Remote but is very busy with singing. Nothing
special happens. Now remote introduces himself to Archos. He does alike.
What comes next? Should Archos throw all the information about the song
and everything he knows about it and the songs on schedule at Remote? I
don't think so. Maybe Remote is very stupid. Then it would have been
enough if Archos told him the number of the song he's singing. Also
maybe Remote is an employee of a big music company and want's to know
every song that Archos could sing. So Remote should ask for the
information he wants. And if Remote has some information for Archos, he
could tell him everything he wants anytime. He could also tell him to
stop singing before asking for any information.
Also i don't think that Archos should be busy looking for Remote while
singing. That might create something like a "Leslie Speaker" effect. ;)
Just not to confuse anybody, Leslie Speakers are loudspeakers that are
mounted on a motor assy. They turn very quickly, what gives a nice sound
effect. I don't know if anybody has implemented a one lien communication
protocol yet, I just ask you to think about the above statement. Yes, it
has advantages to make the Archos the communication master. But who
should decide what to display? The Archos or the Remote? It would be
lots of work and code to put the information for every adapter and
display into the rockbox software. This would likely result in a big
mess and later we'll decide to throw out old remotes, 'cause they use
code space and thus expensive memory. Would be frustrating, if anybody
built his own device. Isn't it easier to give every piece of information
an address (see below) and let the interface/remote decide? This way it
is also possible to connect older remotes to newer rockbox versions and
newer remotes to older rockbox versions. If the rockbox software does
not have the information that is requested it could answer with "sorry,
don't have that available" (nack).
This solution could use serial adapters, remotes and a whole bunch of
other devices one might think of. It is also possible to detect
connection of the jukebox with a PC. No limitation to any platform.
Don't limit yourself by implementing a controller timing self-update
scheme (talking about the controller keeping track of the title time,
what would force us to keep the controller always full running). We
don't have comms overhead here. The polling could be rather slow (1/10
sec?), that would be less communication than updating every information
on a time-based basis. Also when powered up, the polling is not our
problem. It's the LCD that draws 50% of the battery power!
Regarding the last mail: If archos will be master, I also think that
Remo's solution would be best. But please do me one favor: Don't talk
about "avoid polling", when sending lots of unused data to the remote is
the answer. Every communication keeps the controller running and drains
batteries. The polls are *very* short and use considerably less
computation power on the remote. And think of the lost possibilities of
an open protocol (read further). As you stated: This would be a complex
solution rather than the easy and flexible (and power saving!) polling
Stefan: Sorry, i don't have information about sony / pioneer or any
other consumer device protocol.
Björn: Thank you for pointing to the Sony remote project. Maybe it is a
similar protocol. Sadly I don't have any of theese devices. Well, if
somebody owns them, maybe he could find somebody with a good digital
oscilloscope and record some comm dumps?
With the polling solution we are able to to an easy to use RC5 remote
When first implemented the communication with windows (could do that) or
linux, everybody can experiment with his own ideas (Sony on COM2?)
>>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
>Not if we aren't using UART compatible protocols ....
But why should we do that? They are easy, widespread, well known and
reliable. Don't know anything better for one line bidirectional
communication. Ok, there's CAN-bus. It has a sophisticated error
detection and correction scheme, priority control and can handle a
multimaster bus. But then the SH1 would spend 50% of his time to
simulate a low speed CAN-bus. Ok, there'e LIN. It is automotive
standard, but also it is a very stupid protocol for very stupid sensors.
Anything I forgot?
>>Battery drain for frequent polls of the remote is not a problem, if a
>>UART is used. Frequent LCD updates will draw more power.
>I am not really concerned about power-drain caused by polls when the remote
>is plugged in (it's probably possible to design either system to consume
>roughly the same power). What I am concerned about is the remote continuing
>to poll when it is not plugged into a unit. This will rapidly reduce the
>life of the battery.
I won't draw the battery. Even if it is plugged in and the jukebox is
switched of. When the remote polls the Archos it awaits an answer. If
the Archos does not answer for three or more times, the remote could
safely shut down. Since the system is now in a stable (idle) mode, the
remote will not wake up until it is necessary. Thus it will neither draw
the battery nor will it be in an undefined state. That way it is also
possible for the remote to react properly to software crashes and sudden
shutdowns that might be caused by empty jukebox batteries.
>At a quick 5 min search; parts like
>http://www.dataimage.com.tw/product/cm/pdf/CM1610NR-J2.PDF have 2mA
>consumption (typical). I'm certain we can find something lower than this.
>CR2032 usually store ~ 200mA (see
>2) so a 2mA LCD would give us ~100 hours of operation (if we get the uC
>design right, we can ignore the consumption of this - but this will require
>a good design). If we go for something a little bulkier, we could use a
>small NiCad or NiMh rechargeable, and trickle from the signal line to extend
>the life. It's possible we could use run this re-charge current into the
>black if we get an LCD that is low enough in power, and the circuit is good
>enough. This would be necessary to use something as small as a 1/3 AAA, due
>to it's low capacity
Well, theese are standard LCDs used in industrial applications. It you
look at the drawings, the are quite big for an in-line remote control. I
think something in the size of an Archos display or even smaller would
be nice. And as you already calculated, the uptime for the remote would
be about 100 hours with a CR2032 and 2mA display current. I often let
the jukebox play when I'm at the office (we are not allowed to put mp3
files on the company's PCs ;), so I would end up in a 10day battery
life. Even if I only use the jukebox on my three hour workout every
third day (which I do), the battery would last about 3 months. What
would you do with a calculator that needs new batteries every three
months? I'm wearing a pulse meter during workout. It also uses CR2032 in
both units. They managed it to power a RF transmission and receiver
unit, the display and the pulse sensor with two CRs. The device works
for about a year now without byttery replacement. Well, if we go for
bulkier things, we could use the cigarette lighter plug or even three AA
batteries. But that's not very usefull for i.e. jogging. It would be
o.k. for a Sony interface.
For a good design, we should use all available techniques.
Just take a look at: http://www.lcd-module.de/deu/pdf/doma/s_7123.pdf
(Only first page is in german, rest english).
E/A offers modules that are just 2.65mm thick, have I2C bus, use only
500µA (at 3V), have 3x12 characters, are very small in size (46x33mm).
Well, maybe it needs an additional negative supply, but that can be
generated by an AVR via PWM and a very small coil. Or if that is not
goot, we could use a graphics display with build in negative supply
generator. You can see it on
http://www.lcd-module.de/deu/pdf/grafik/w128-6f8.pdf. Sorry, german
only. It's also very thin, yet bit smaller in display size. It has a
high resolution of 128x64 dots and uses a single 3V supply. It also has
serial and parallel connection. But this display also will draw lots of
power (about 1mA I think).
Talking about communication issues and insertion detection:
>Isn't this a 'spike'? I proposed a similar system in my previous
>email -what difference are you proposing here?
Yeah, you're right. But this here is only used for insertion detection
and is not used in normal communication mode. There might be other ways
to detect insertion, but I recommend this, because it won't do any harm
to the controller or the original remote. We should not use this for
normal communication, because that is something the UART normally would
filter out. Maybe you have another idea regarding insertion? I'm not
very happy with this one. Maybe we also could use a standard UART wakeup
signal, if the original remote is protected. Possibly the insertion
shorts some pins of the plug, that would be great! I know that sounds
stupid, but could be used for controller wakeup if configured properly.
It's much alike wakeup on key press.
>>Just to answer the questions regarding power: It is absolutely necessary
>>to put the controller in total halt mode.
>It is simpler to do this. It is ideal in a current consupmtion sense to
>have the remote shut off it's power with a FET switch, or such like. It
>should certainly operate in it's lowest power mode that interupts can wake
>it up from during operation, and most uC's lowest power mode would be
>acceptable for multi-month to year long length shelf lives (they usually
>scale down to 1-10s of uA, so on a CR2032 that's 200mA/10uA (worse case) =
Erm, well, you can't switch off the controller, can you? Who would
detect the pin change then? Also it is not necessary to switch off the
controller electrically. It draws less than one microamp in halt mode
and is able to detect the pin change. It is common practice to leave
controllers in remotes powered up all time. We also don't need a FET
switch for the display. A good controller is capable of driving up to
10mA through the outputs. So the display could be switched off by the
controller itself. We should not use a controller, that consumes more
than a 1-3 microamps in power down. That eliminates all FET switches and
makes the device cheaper and smaller. 300 nanoamp is state of the art
but very expensive.
>That's why we're talking. I doubt anything is going to be implemented
>without an error detection protocol at the very least.
You're right. To put a little more detail in that issue, I'm thinking
about something like an easy "keyword 2000"-protocol. The simpler
version could be much easier than the original. Maybe something like this:
1.Byte: Length (including length, header, data and checksum)
2. Byte Header (similar to function)
3. .... 3+n th Byte: Data
4+n th Byte: Checksum
Theese Blocks are universal and could be handled by a simple software
layer without knowing anything about the information that is contained.
This layer could also check timeouts and react properly. This way the
apllication only has to deal with "certified" information. Also this
scheme has a lot of advantages (we would have to define the blocks, most
important general ack and nack blocks). So a remote can send a request
for title name (lets say function 5) and the player can answer with an
updated time (maybe function 7), because that is more important. Well,
the Remote could ask again or maybe also send a keypress event.
Basically both can send anything they want without confusing the other
side. That's a great advantage. I'll put some statements on bus
aquisation here later this week, 'cause I'm running out of time...
>I hope I haven't come off as too negative here. I enjoy discussing
>technical issues, (as, I would imagine, do most on this group - hence why
>they are here), and am happy to be proven wrong (as has often happened).
So do I. No, you haven't come off too negative. Thought I did. Joining
the discussion and writing that bunch of text.... ;) I think this is
just a starting point and many things might change while testing them.
Well, at least it should be fun for everybody!
George Styles wrote:
>That all sounds very interesting. You obviously know more than me about
Maybe, I don't know your resume ;) I work for an automotive company
that specialized in "body electronics" for over 7 years now. By the
time, I've implemented more than 20 different protocols on at least 8
busses, because that's a huge part of my job. Electronic devices in cars
do a lot of communication theese days. There have been a lot of both
good and bad protocols and would like to see a good one in rockbox!
>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).
Won't be easy, but will be worth putting some effort in it.
>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...
If there are about 300 interested people, the device wouldn't cost that
much. I know a few companies that specialised on low volume production
of electronic devices. They're doing all our prototypes.
>nice work :)
Andreas aka radhard
Page was last modified "Jan 10 2012" The Rockbox Crew