[mythtv-users] another DCT2000 query

[Ray Olszewski]

Thanks for your contimued patience, Ian,  with working this out. At this 
point, I'm taking the time to keep talking about what I'm doing mainly for 
the benefit of others ... I see with some regularity prople posting about 
their puzzlement, and sometines concluding, perhaps prematurely, that they 
do not have active serial ports on the DCTs. Despite its rambliness, I hope 
this discussion will help others consider a broader, more aggressive range 
of testing possibilities.

As to the Python script ... my problem was carelessness in phrasing. There 
isn't a "the" Python script. There are several, and I was using an outdated 
version. I got the version packed with mythtv-0.14 and it works (requiring 
only the trivial change of serial port designator to ttyS0) almost perfectly.

The "almost" is just a note that it needs actual 3-digit channel codes on 
the cl -- for example, "./changechannel.py 068" changes the channel but 
"./changechannel.py 68" does not -- so the "pad to 3 digits" step in the 
code may have a bug. (Remember that DCT2000s can be set to respond to 1- 
and 2-character channel codes ... so some users of the script will not be 
testign whether it always sends 3-digit codes. My DCT is set to expect only 
3-digit channel codes.)

I'm now wondering if the problem I'm having with the C program derives from 
its using a long, fixed-length payload -- 128 bytes instead of the 
variable-size payload -- typically under 6 bytes -- the Python program 
creates. (My own Perl program dodges this issue by using a lookup table 
with predefined payloads, including CRC, for each digit.)

Since the C program was developed and tested with a DCT2224 ... is there 
anyone using it successfully with a DCT2000 on (Comcast)? If not, I'm 
inclined to guess there is a difference that matters between the two models 
... easy to believe given all the detective work that's been needed to 
figure out the codes involved. If yes, then I need to do more work.

Other odds and ends:

I've used the serial port on this host enough to rule out the possibility 
of it being defective. I suppose the successful use of the Python program 
confirms this.

The TiVo story I told was not confusion between the IR Blaster and 
serial-port controls. If you thought so it's because I told it in too 
abbreviated a form ... I left out the story of the "bad experience". My 
friend had hooked up the serial port and used it for some time to change 
channels on his DCT2000. It then stopped working (the channel didn't 
change, but the TiVo thought it was changing channels). He checked it and 
found that the cable had come loose. He plugged it back in, and it started 
working again. It's hard to interpret that as his actually using an IR Blaster.

Just to be completely clear now -- at this point, either the Python program 
or my own Perl program WILL change channels successfully. Loose ends are 
only (1) why the C program will not get past the initial communication 
stage and (2) whether 2-way communication is supported by this DCT. If you 
(Ian) or anyone else has insights, I'd love to read them ... but we're now 
down more to curiosity than in a struggle to make things work at all.

Thanks once more for your help.

At 10:34 PM 2/18/2004 -0800, Ian Forde wrote:
>On Wed, 2004-02-18 at 21:27, Ray Olszewski wrote:
> > Thanks again, Ian. Just responding to clarify a couple of things you
> > wondered about. I'd welcome any added advice you have ... but I'm also
> > making progress here as things stand.
>
>No problem - responses inline...
>
> > It sent some packets, which is how I confirmed that the DCT's serial port
> > was working. But the internal documentation for the Python program is a 
> bit
> > sparse, and I'm not a Python programmer anyway, so I couldn't figure out
> > how to get it to send the specific instructions I wanted it to send. Is
> > there someplace that describes what command-line arguments this program
> > responds to? I didn't find one in the stuff I had with it.
>
>S'okay - I'm not a Python programmer either.  And since I haven't looked
>at this code for a WHILE, I may be a little rusty.  (Most people I
>believe are now using the C code that Jim Paris wrote.  He's got more
>error-checking and has figured out the response codes.)  Having said
>that, I wrote the documentation for the script (check the README file).
>The logic is simple.  First, some functions are defined.  Checking for a
>string parameter versus a numeric parameter, getting a response from the
>serial port, sending a code to the unit, etc...
>
>Next, we parse the parameter.  There's some code that's unused by myth
>that lets you mute the cable box, go back to the last channel, etc,
>based upon if the script if given one of several letter arguments
>instead of a channel number.  If it's a letter argument, we figure out
>the code, open the serial port (line 174) and send it to through the
>port (line 175).  Otherwise, we pad the number to 3 digits, create a
>concatted string to send out, open the port (line 196), and send it to
>the box (line 197).
>
>So basically, the arguments are:
>
>l,m,f,u,d or a channel number.  No dashed options whatsoever...
>
> > [...]I have no doubt it is enabled. I'm using it (under manual or 
> cron-script
> > control) now.  The question I can't resolve is whether it does two-way
> > communication.
>
>Okay - this I've run into.  Turned out I had a bad serial port on myth
>box.  I kid you not.  Try it on another serial port or with a different
>serial cable.  (You can even use a 9-pin RS232 to RJ45 adapter that
>comes with Cisco routers with a straight through Cat-5 cable to a RJ-45
>to DB25 cable used for Sun consoling.  Stick a null modem on that and it
>might do the trick...)
>
> > 1. The C program cannot get a response in its initialization section.
>
>Yep - consistent so far...
>
> > 2. The Python program claims it gets responses, always the same packet (or
> > always the same in response to a channel-number packet, anyway). But since
> > I don't have any docs on how the DCT is supposed to respond on the serial
> > port, I don't know if it is getting real responses of something Python'ish
> > that I don't understand.
>
>Reboot the PC, power off and on the cable box, and try again.  Bear in
>mind - I have the serial hack for my Tivo as well, and if my Tivo
>reboots (due to power failure, etc...) I have to power cycle the cable
>box otherwise the Tivo stops accepting remote codes due to some
>deadlock.  Turns out Tivo likes to response codes too.  Thus, it might
>not be a bad idea to script in a power-cycle code of the cable box when
>mythbackend starts.  The C code will do this if it can't get a channel
>change through after a certain number of attempts.
>
> > 3. The Perl program I wrote to change channels does not get responses from
> > the serial port. Outgoing packets to the DCT go through fine, though ...
> > which contradicts the claim in the comments in the Python program that the
> > DCT's reply has to be read before the DCT will accept another packet.
> >
> > 4. A neighbor has the same cable service and DCT model, and a TiVo. He
> > tells me his TiVo can change channels but cannot do anything that requires
> > it to get information from its DCT (like know if the serial cable is
> > connected ... my friend's example from bad experience).
>
>That may be a red herring.  If he's got a D-Tivo or a standalone Tivo
>with the serial hack, his serial cable is being used.  But there are
>many out there who have a serial cable connected, believing that it
>works, when in point of fact it's the internal IR transmitter in the
>Tivo that can penetrate wood (believe it) to change channels in the DCT
>box.  If he's got a standalone Tivo, make sure that he's got the hack
>that gives him the serial cable menu option.
>
> > You see why I am uncertain.
>
>Yepper!