Menu
▾
▴
Re: help with EchoStar 119420 remote
|
From: Endaf J. <jo...@ze...> - 2005-10-05 03:57:21
|
Kipp Cannon wrote: > On Tue, 4 Oct 2005, Endaf Jones wrote: > > [snip] >> I've spent the better part of 40 hours making the Echostar protocol >> exact. Try the following. You MUST use the latest CVS version of >> lirc due to a recent fix with NO_HEAD_REP. This is still work in >> progress (when I get time). The other files you list above are >> somewhat broken. > > Ah... I had begun to suspect there are bugs in lirc. After a lot more > mucking around, I arrived at the following set of parameters that give > very accurate transmission > > flags SPACE_ENC|NO_HEAD_REP|NO_FOOT_REP > header 501 6077 > one 501 1650 > zero 501 2711 > ptrail 501 > foot 501 6077 > repeat_gap 6077 > gap 6077 > min_repeat 1 > > Less than one button transmission in 100 is missed by the satellite > receiver when using these parameters. That's *only* for transmission. > For reception, this configuration doesn't work at all --- lirc doesn't > understand a single button press. If, however, I get rid of the foot > and repeat_gap, then it almost works. lircd still gets repeat > counting wrong, but it sees every button press quite well. Of course, > then transmission is completely useless. > > For the life of me, I have not been able to produce a set of > parameters that can get lirc to send *and* receive, and this suggests > a bug: it looks like a given set of parameters describes a different > waveform to the receiving code than they do to the transmiting code. > > Is it possible that the NO_FOOT_REP implementation has the same bug > that was in NO_HEAD_REP? This remote needs to use both of these flags. > >> This file supports ALL of the remote addresses (1-16). You can play >> with min_repeat. The remote I believe sends only 1 repeat if you hit >> the button very quickly. But, the receiver may not pick it up all >> the time. Try between 4 and 6. You'll need to space out your >> irsends for each character as well (perhaps 1/3 second between sends) >> >> I will formally ask to have this published when I have the timings >> correct (you may need to adjust the timings slightly to make it work >> for your hardware). >> >> begin remote >> name echostar1 >> flags SPACE_ENC|NO_HEAD_REP >> eps 30 >> aeps 100 >> >> frequency 56000 >> # duty_cycle 32 >> >> one 440 1665 >> zero 440 2820 >> >> header 525 6130 >> ptrail 450 >> gap 6200 >> >> min_repeat 4 >> >> bits 6 >> post_data_bits 10 >> >> >> # unit code selection (1-16) >> # 1=0x000 2=0x200 3=0x100 4=0x300 >> # 5=0x080 6=0x280 7=0x180 8=0x380 >> # 9=0x040 10=0x240 11=0x140 12=0x340 >> # 13=0x0C0 14=0x2C0 15=0x1C0 16=0x3C0 >> >> post_data 0x000 >> >> >> begin codes >> 1 4 >> 2 5 >> 3 6 >> 4 8 >> 5 9 >> 6 10 >> 7 12 >> 8 13 >> 9 14 >> 0 17 >> power_on 1 >> select 16 >> cancel 18 >> >> >> # info 0 >> # power_on 1 >> # power 2 >> # 1 4 >> # 2 5 >> # 3 6 >> # 4 8 >> # 5 9 >> # 6 10 >> # menu 11 >> # 7 12 >> # 8 13 >> # 9 14 >> # select 16 >> # 0 17 >> # cancel 18 >> # guide 20 >> # view 22 >> # tv_vcr 23 >> # right 24 >> # up 26 >> # recall 27 >> # left 28 >> # down 30 >> # record 31 >> # pause 32 >> # stop 33 >> # sys_info 36 >> # asterisk 37 >> # pound 38 >> # power_off 39 >> # sat 41 >> # dish_home 52 >> # sys_info2 54 >> # dish_home2 56 >> >> >> end codes >> end remote > > This is great info, thanks. However, why does this configuration not > mention the foot pulse? Perhaps that's why you find you need to > increase min_repeat, since I've found that min_repeat=1 is fine (now > that I've found a configuration that works for transmission). The > foot pulse appears exactly where the first data pulse would appear in > a subsequent repeat, so in effect you might be using the extra repeat > to simulate the foot pulse. > > I will definitely try upgrading to lirc's current CVS and see if this > allows a single configuration to work for both transmission and > reception. > > What about the modulation duty cycle? I see that you've commented it > out? Why is that? > > On a different note, your breakdown of the 16 bits of data into a > 6-bit button code and a 10-bit unit code is not shared by all Echostar > remotes. Or maybe it's more accurate for me to say that not all > remotes behave sensibly in this regard. My model 119420 is *very* > close to behaving the way you describe, but two buttons generate codes > that differ in the last 10 bits. Actually, they differ in bit > 0x0010. These are the "page up" and "page down" buttons for scrolling > through program guides. My button codes are: > > bits 12 > post_data_bits 4 > post_data 0x0 > > begin codes > TV/VIDEO 0x5C0 > POWER 0x080 > PAGEUP 0x3C1 > PAGEDN 0x1C1 > MENU 0x2C0 > GUIDE 0x500 > UP 0x680 > LEFT 0x700 > SELECT 0x400 > RIGHT 0x600 > DOWN 0x780 > RECALL 0x6C0 > INFO 0x000 > VIEW 0x580 > CANCEL 0x480 > SYS_INFO 0x900 > RECORD 0x7C0 > 1 0x100 > 2 0x140 > 3 0x180 > 4 0x200 > 5 0x240 > 6 0x280 > 7 0x300 > 8 0x340 > 9 0x380 > * 0x940 > 0 0x440 > # 0x980 > end codes > > Thanks again, this has been helpful. > > -Kipp Kipp, Yes, you can play with the timings, the receiver is quite forgiving at times. If you try your remote and only do a very quick keypress (so that it only repeats ONCE) you can get the receiver to miss a keypress. It's not safe to only send the mininum of 1 repeat (and what's the point anyway?). You'll need 3 or so to be safe. Don't assume your environment is totally absent of stray IR light! There is stray IR light from a lot of sources. (Fluorescent light at startup is a good source for many seconds). Yes, there are other codes that use one of the bits from the Device field, but you don't normally need them. The extra codes were added when their receivers got fancy (like the PVR lines). A generic 301/3100 or classic 2700 receiver doesn't need them. The protocol is broken down as follows <Key 6 bits><Unit 5 bits><Device 5 bits> The order of the bits are MSB first except for the UNIT where it is sent LSB (that's why I need a table in my lircd.conf file to map the remote address). <Key 543210><Unit 01234><Device 43210> What they did was keep the standard keys on Device 0 and add the extra needed buttons to Device 1 (if my memory is correct). With my setup, you can't change the device independently within a single remote code section. Basically, the PVR remote that Echostar uses is actually using one of two devices depending if it's a normal key or a extra functionality key. If you're just using lirc to change channels on your receiver, you don't need all those extra keys anyway. It is strange that you're making the Echostar remote control your PC. Normally, one would use lirc to send IR's via the Echostar protocol at 56kHz and receive via some generic protocol at 38kHz (Philips RC5 is popular with Hauppage cards). I'm not too sure why you want lirc to receive Echostar stuff? 56kHz is very taxing on the system with a homebrew receiver. You may want to look at getting a generic programable remote (that is JP1 capable). The duty cycle of the Echostar protocol is appearently at 33%. My hardware transmitter does not support this (and it really doesn't matter anyway as the front end chip of the Echostar receiver doesn't see any difference between 33% and 50%). Hope this helps. # Endaf |