|
Rockbox mail archiveSubject: Re: new thread about remote control with displayRe: new thread about remote control with display
From: Andreas Zwirtes <zwirtes_at_gmx.de>
Date: Wed, 09 Oct 2002 00:08:23 +0200 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 battery. 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 controller. >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 data. 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). Stuart: 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 scheme. 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? Some ideas: With the polling solution we are able to to an easy to use RC5 remote control. 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 >>UART. >> >> >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 >http://www.sanyo-energy-europe.com/content/industrial/detail.php?model=CR203 >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 >(http://www.sanyo-energy-europe.com/content/industrial/detail.php?model=N-50 >AAA). > 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) = >~2.3 years > 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 >this... > 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 :) > thank you! Andreas aka radhard Received on 2002-10-09 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |