JP1 Remotes

Nils_Ekberg · Posted: Thu Feb 22, 2007 11:25 am Post subject:

I have a few parallel port cables and they have been very effective over the years. A few laptops ago I had to go with the USB because that is all the new one had and I really had good luck with the USB cable for a few years with very little problems.

At one point I did have a serial cable that worked just fine for the jp1 remotes I have (quite a few) but gave it away when all I had was USB.

Now I have a few parallel cables (simple and advanced), a jp1.1 serial and a jp1.2 serial and of course the USB which I can't get installed on this laptop.

I may have to bite the bullet and reinstall XP as Microsoft has suggested since neither they or Delcom have been able to figure this out. Part of the problem is the .inf file is the old format and I don't know enough about inf files to upgrade it.

Thanks
_________________
Nils
Files Section
Diagnosis File Section

whompus · Joined: 27 Apr 2005 Posts: 540

Nils... Before you do a complete reinstall, You might try this thread http://www.hifi-remote.com/forums/viewtopic.php?t=5599 I have had to do those things more then once when setting up jp1 for friends and such on new laptops.

Nils_Ekberg · Posted: Thu Feb 22, 2007 1:32 pm Post subject:

ElizabethD · Advanced Member Joined: 09 Feb 2004 Posts: 2348

Nils, considering other Dells worked, have you talked to Dell or just Delcom? Perhaps they did something funny in that model or perhaps there's a tech bulletin someplace on their site.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile

Nils_Ekberg · Posted: Fri Feb 23, 2007 8:26 am Post subject:

Mark Pierson · Posted: Fri Feb 23, 2007 9:33 am Post subject:

It's a long shot, but check the power save settings on the USB ports. I've heard Dell is notorious for putting their USB ports to sleep on laptops. I think you find those settings under the ports themselves in the Device Manager.
_________________
Mark

Nils_Ekberg · Posted: Fri Feb 23, 2007 10:18 am Post subject:

Mark

It is a long shot but worth a try.

I had checked at the BIOS level and it was set for always on but in the Device Manager "USB root hub's" it did have a power option to "allow system to turn off the port to save power" checked. I unchecked each one and will try it when I get home.

I know that XP is finding the device since when it is plugged in it presents the VID and PID correctly which I can see in the install log. After I point to the driver it just comes back and says "The hardware was not installed because the wizard cannot find the necessary software." then goes on and installs it with the unknown device driver.

The USBIODS INF has not been updated since 2004 and seems to be a very old style which may have some impact also.
_________________
Nils
Files Section
Diagnosis File Section

unclemiltie · Posted: Fri Feb 23, 2007 10:37 am Post subject:

ever try putting the software on a separate (and not encrypted) disk like a thumb drive or a CD?

If XP is finding and identifying the device on install (do you see an unknown device in the device manager when it's plugged in?) by the right VID/PID, you're nearly all the way home. The INF file format should not be your problem in that I know of many copies of XP SP2 that installed this driver.

Something else is getting in your way here. The INF driver install is only looking for two things, the INF file and the SYS file. I don't see it needing anything else in a quick scan of the INF

The INF file doesn't have a whole lot in it, but one thing that is interesting is there are two VIDs, maybe you haven't searched out all old registry entries?

from the INF:

%String2%=USBIODS.Dev,USB\VID_0FC5&PID_1222
%String2%=USBIODS.Dev,USB\VID_6969&PID_1222

Also from the INF, it's adding the following keys to the registry, you should go find them and delete them all (related to the Delcom)

HKR,,DevLoader,0,*ntkern
HKR,,NTMPDriver,0,USBIODS.sys
HKLM,System\Currentcontrolset\Services\Delcom\USBIODS\Parameters,DebugLevel,1,00
HKLM,System\Currentcontrolset\Services\Delcom\USBIODS\Parameters,BootupTest,1,00
Mine is 0FC5 and I know you searched for and rooted this one out, but did you go after the other as well?

In the end, the symptoms that you describe say that it's not finding the INF and SYS file on install and failing and that your registry cleaning exercises have been successful. (otherwise it wouldn't even ask as it thinks the drivers are already installed)

This one has me scratching my head......

Nils_Ekberg · Posted: Fri Feb 23, 2007 11:03 am Post subject:

Tommy Tyler · Posted: Fri Feb 23, 2007 11:36 am Post subject:

When the design of the combo-interface was released, an elaborate software initialization scheme was included that relied on separate drivers for pins 4 and 5 of the interface. Pin 4 was held low during reset to initialize a JP1.2 remote, and pin 5 for a JP1.1 remote. That scheme is described in detail here: http://www.hifi-remote.com/forums/dload.php?action=file&file_id=4259. If I understand correctly, binky123 is suggesting you can upgrade an interface built for JP1.2 only (without the three components R1, D1, and Q1) so that it will operate with JP1.1 remotes also, by just connecting pins 4 and 5 together.

When a JP1.x remote comes out of reset there are four possible combinations of pins 4 and 5 that decide what happens next:

.......PIN 4......PIN 5...............JP1.2 ACTION......................JP1.1 ACTION
(1).....1.............1..........start normal operation..........start normal operation
(2).....0.............1..........go to serial comm mode...................?
(3).....1.............0..........go to background mode........go to serial comm mode
(4).....0.............0.......................?.......................................?

The fourth condition can occur only if pins 4 and 5 are tied together. We don't know how the remote software is written, or even whether it is the same for different version remotes, so we don't know the results of condition (4) for JP1.2 or conditions (2) and (4) for JP1.1 except from experimental evidence.

Consider first the JP1.2. Since condition (4) is ambiguous (it's telling the remote to do two different things) it may or may not have been specifically dealt with in the remote's software, depending on the skill and imagination of the programmer. Some programmers might decide that, since this as an invalid combination, to treat "0 0" the same as "1 1". But for the binky123 scheme to work, the software has to be written to treat condition (4) the same as condition (2), by looking first at pin 4 and, if it is low, disregarding pin 5.

Now look at the JP1.1. Here the programmer has the option of disregarding pin 4 altogether, so that condition (2) is equivalent to (1), and (4) is equivalent to (3).

For testing with JP1.1 I used a Comcast URC-1058BG0 remote. Most of the time the remote did initialize into serial comm mode with both pins 4 and 5 low, but every once in a while it would come up in a state where it was neither operational nor willing to communicate. It remained in this limbo state indefinitely until I sent a break signal, which kicked it on into serial comm mode. I conclude from this that there may be a timing issue. Perhaps the remote sees pin 5 low following reset, starts serial comm mode, then sees pin 4 low and has to wait for that to clear to move on.

For testing JP1.2 I used a URC-10820B00 remote. Resetting the remote with just pin 4 low initializes it in serial comm mode as expected, but resetting the remote with both pins low always left it in a state where it would neither operate nor communicate, which I assume is background mode. That suggests that when the processor comes out of reset it looks first at pin 5 and, if low, disregards pin 4.

All the foregoing tests were made with an interface having manual switches for holding pins 4 and 5 low, either separately or together. For thoroughness I decided to make an adapter that actually wired pins 4 and 5 together, and let the test software program (which I am sure embodies the initialization sequence described in the link above) do the startup. I almost wish I hadn't. The remote always initialized in serial comm mode, which contradicts the last sentence of the above paragraph. Go figure.

My conclusion is that the binky123 scheme may or may not work at all times with all remotes. You can try it, and if it seems to work for you, great. If the results are unsatisfactory you will have to put in the three optional components.

Tommy

binky123 · Expert Joined: 14 Feb 2004 Posts: 1292

Tommy Tyler · Posted: Fri Feb 23, 2007 2:44 pm Post subject:

binky123 · Expert Joined: 14 Feb 2004 Posts: 1292

ElizabethD · Advanced Member Joined: 09 Feb 2004 Posts: 2348

Two subjects going on here - wiring and Nils. My five cents for Nils:

There seem to be two versions of driver .inf files, 2004 and 2005. 2005 has fixes like unlclemiltie mentioned, plus one more: how the service starts. M$ says PnP devices have to have value 3 (demand), not 2 (auto start) for .AddService which is in the 2004 file, but I think service startup mode is not relevant, since Nils doesn't even get to trigger it. Also unclemiltie is onto something about encryption, but I know nothing about it.

whompus · Joined: 27 Apr 2005 Posts: 540

I to suspect he has went down this path.

In Xp pro it is under Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options with 3 options, silently succeed, warn but allow, and don't allow.

I still think it has more to do with some weird oem driver blocking it then security settings, but one never knows.