 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
 Posted: Tue Apr 27, 2010 6:34 am Post subject: Automated analysis of IR protocols |
 |
|
I have been investigating how far it is possible to take automated analysis of IR protocols. The result is incorporated into ExchangeIR.dll v0.05. I have enhanced IRScope to take advantage of this new capability and have posted it as IRScope 2.01 Beta 3. This package includes ExchangeIR.dll v0.05.
The new analysis appears in the Summary display as a description of the signal in IRP notation. Here is a screenshot showing the Summary screen with a varied collection of protocols:
There is no look-up involved. The IRP form is constructed entirely from an analysis of the signal and should work with a wide variety of signals whose protocols are unknown. I hope it will be a useful tool in the analysis of such protocols. Here is an example of how to interpret the output. The IRP form of signal 1, Pace protocol, shows as
{38.2k,633,msb}<1,-7|1,-11>(1,-5,1,-5,A:10,1,-89)+{A=$304}; Alt leadout form: ^123m
The IRP for the Pace protocol given in DecodeIR.html is:
{38k,630,msb}<1,-7|1,-11>(1,-5,1,-5,T:1,D:1,F:8,1,^120m)+
The correspondence for the most part is obvious. Automated analysis cannot split the data bits into device and function codes, etc, so it shows all the data concatenated as A:10, i.e. the value of A expressed in 10 bits. This value is given in hex form in the curly brackets. Writing $304 as 10 bits gives 1100000100. This corresponds to the T:1, D:1, F:8 of the DecodeIR.html form with (again in binary) T=1, D=1, F=00000100, or in decimal as T=1,D=1,F=4. This agrees exactly with the description of item 1 on the IRScope main screen.
Automated analysis often cannot determine whether the lead-out is an absolute value (the -89 given in the IRP expression) or a cumulative value (the ^123m given as an alternate form), so both are given in this case. Sometimes it is possible for an automated determination, such as when two lead-outs occur which agree in one form but disagree in the other form. This is the case in signal 6, NECx1 protocol:
{38.1k,562,msb}<1,-1|1,-3>(8,-8,A:32,1,^108m,(8,-8,B:1,1,^108m)+){A=$E090F00F,B=$0}
as the main frame and the ditto repeat have lead-outs with different absolute values. The Nokia protocol shows up with a different form to the usual one:
{34.5k,msb}<-164u|174u,-268u>(<1:-1|1:-2|1:-3|1:-4>(424u,-259u,A:24,176u,-91.4m)+) {A=$0E0004}; Alt leadout form: ^99m
In the inner bitspec, 1:-3 (for example) means 1 expressed as 3 bits (001), but the minus sign means that the order is reversed from the msb order specified in the initial curly brackets. This is standard IRP notation, not an invention of mine. So 1:-3 means 100 encoded according to the outer bitspec, i.e. 174u,-268u,-164u,-164u. Adding the consecutive OFF times gives 174u,-596u. The DecodeIR.html form is
{36k,msb}<164,-276|164,-445|164,-614|164,-783>(412,-276,D:8,S:8,F:8,164,-???)+
The slight differences in values are inherent in the signal and are not due to the analysis. It isn't actually necessary to understand the bitspec notation to extract the data, however, as this has already been done in the value A=$0E0004, i.e. D=$0E=14, S=$00=0, F=$04=4, again in agreement with the main IRScope screen.
The analysis works by looking for patterns in the signal, often in a hierarchy of increasing specialization. It outputs the most specialized form that it finds. This can occasionally lead to unexpected results. For example, the Pace protocol above is also represented by
{38.2k,633,msb}<1,-5|1,-7|1,-9|1,-11>(A:24,1,-89)+{$F5575}
which looks very different but which corresponds to the same IR signal. The first form is more specialized, so that is output, but a poor read of the signal might prevent the specialization being recognised, resulting in something close to this second form being shown. It is also possible for accidental patterns in the data to result in a more specialized form being output than is warranted by the protocol as a whole.
The analysis will recognise a straightforward repeating pattern from two occurrences, but less straightforward repeats such as "ditto frames" require three occurrences, i.e. the main signal plus three dittos. DecodeIR is very forgiving of poor signal reads, which can result in spurious identifications. This ExchangeIR analysis has the opposite problem. It requires a good read, as every burst is examined, so DecodeIR may show an identification when the ExchangeIR analysis returns "Undetermined".
Because some protocols unknown to DecodeIR result in spurious decodes which can potentially upset the automated analysis (by breaking the signal at the wrong points), there is a new option on the Advanced menu of IRScope, to Disable Decoder. All signals then show as "<unknown>" but the Summary still shows the analysis and IRP form of the signal.
Finally, it is not necessary to have a Widget in order to use this analysis as IRScope now has the ability to import signals in either Pronto or UEI Learned forms.
I think this should be enough to enable the output to be understood. I await comments with interest!
________________
Graham |
|
| Back to top |
|
 |
ElizabethD
Advanced Member
Joined: 09 Feb 2004
Posts: 2348
|
| Posted: Fri Apr 30, 2010 4:37 pm Post subject: |
|
|
Wow, what an interesting, difficult, project and wonderful results 
I'm not qualified to address any important technical things that'll be so useful to protocol writers, so just few miscellaneous notes.
I played with an unknown remote of my neighbor. For Verizon FIOS. It's not a UEI remote - all setup codes are wrong and using them is not the usual UEI sequence.
I put in few devices and all the decodes I tried are super.
One thing I'd love to see is bits for the hex values such as {A=$400401008485}, if the hex string is longer than 16 bits. Panasonic has 48 and 56 bits, kinda long by hand and excel can only do 16 bits at a time without concatenation.
Another - even though Hex is reported above the detailed section, I'd like to see it next to OBC here as well.
I'd like to see under the Import button an option to Import a widget file because Windows is fighting me on file association again: when I double click a widget file it insists on using beta2 even though I point to beta3. For the life of me I can't ever remember how to fix in registry. Windows fights my IR versions as well.
Now, a OT decoder note, mostly FYI
1. GI cable comes out as Undetermined
2. I used 2 of their Mitsubishi setup codes. I expected to see Mitsubishi or JVC for those. Instead, I got Proton in one instance, Sharp in another. Both report device 240, obc 64 (hex FD) I think it was for power. The Proton version first signal is Undetermined IRP form, the next signal does show IRP notation. It could well be that those protocols are just fine of course. I have no way of knowing.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride  |
|
| Back to top |
|
|
ElizabethD
Advanced Member
Joined: 09 Feb 2004
Posts: 2348
|
| Posted: Sat May 01, 2010 6:57 pm Post subject: |
|
|
Graham,
When a protocol in undetermined, unknown, would you be able to put out the bit strings to make figuring out of protocols easier? Or is it not possible if there's something really goofy then it can't be done, like in this
http://www.hifi-remote.com/forums/viewtopic.php?t=12163
where, maybe, IRscope could see A, B, C sections and bit'm from hex
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Sun May 02, 2010 1:12 pm Post subject: |
|
|
| ElizabethD wrote: | | Wow, what an interesting, difficult, project and wonderful results |
Thank you very much!
| Quote: | | One thing I'd love to see is bits for the hex values such as {A=$400401008485}, if the hex string is longer than 16 bits. Panasonic has 48 and 56 bits, kinda long by hand and excel can only do 16 bits at a time without concatenation. |
I'm not clear what you are asking. Do you want $400401008485 written out as a 48-bit string instead of this hex form? I can easily do that, and actually wondered about using binary rather than hex when I was creating this, but I felt it would look very tedious. Perhaps make it a switchable option?
| Quote: | | Another - even though Hex is reported above the detailed section, I'd like to see it next to OBC here as well. |
OK, no problem.
| Quote: | | I'd like to see under the Import button an option to Import a widget file because Windows is fighting me on file association again: when I double click a widget file it insists on using beta2 even though I point to beta3. For the life of me I can't ever remember how to fix in registry. Windows fights my IR versions as well. |
Right-click the IRScope (or IR.exe) version that you want set as your file association and select Run as Administrator. You only need to do that once. The file association for both programs is re-set whenever they are opened in a way that permits writing to the appropriate part of the registry. For older Windows versions this is always the case, but for more recent ones it requires running as (not just logging on as) Administrator.
| Quote: | | 1. GI cable comes out as Undetermined |
This was one of my test protocols and I've just re-checked that it still works for me. I got:
IRP form: {38.1k,249,msb}<2,-9|2,-18>(36,-18,A:16,2,^100m,(36,-9,2,^100m)+){A=$A00D}
Because it is a protocol that uses ditto repeats, the analyzer requires at least 3 dittos for the form to be recognised. You should get a valid IRP form if there are no dittos, but if there are exactly one or two dittos in the signal of any protocol that uses ditto repeats, it will report as Undetermined. If this doesn't resolve it, please send me a .irp file of the problematic signal.
| Quote: | | 2. I used 2 of their Mitsubishi setup codes. I expected to see Mitsubishi or JVC for those. Instead, I got Proton in one instance, Sharp in another. Both report device 240, obc 64 (hex FD) I think it was for power. |
That sounds like a spurious decode from DecodeIR rather than anything from the new analysis program. Could you send me a .irp file of these signals so that I can investigate further? I'll also look into the IRP forms that these signals produce.
In my development and testing I used signals from over 50 protocols, of as wide a range of protocol structures as I could find, and got it to the point where every one of them gave a valid IRP form when the signal was good. However, all the signals came from one remote (my URC-7781) and were the UEI or RemoteMaster versions of the protocols. I expected that when other remotes, UEI or OEM, were used that this might show up the need for further tuning, so I would welcome .irp files of any signals that either show Undetermined or show an incorrect IRP form.
| Quote: | | When a protocol in undetermined, unknown, would you be able to put out the bit strings to make figuring out of protocols easier? |
Remember that there is no connection at all between the DecodeIR result and the IRP form that results from the analysis. "Unknown" is a result displayed from DecodeIR. If the signal can be analysed, it will still show an IRP form with the bit string (currently in hex) form of the data. Here's a signal that turns on my air cooler:
IRP form: {37.9k,421,msb}<1,-3|3,-1>(A:12,-16)+{A=$D81}
I've no idea what the protocol is, it is certainly not known to DecodeIR, but this analysis shows the signal form perfectly.
"Undetermined" is a result displayed by the analyzer in ExchangeIR. It is possible, as you saw with GI Cable, for DecodeIR to identify the protocol but for the analyzer to return Undetermined. If you get both Unknown and Undetermined then everything has failed and I have no way of extracting the data bits. But as I said above, I will examine signals that return Undetermined, if I have the .irp file, to try to find out why the analysis has failed and if I can tune or otherwise improve it.
__________________
Graham |
|
| Back to top |
|
|
ElizabethD
Advanced Member
Joined: 09 Feb 2004
Posts: 2348
|
| Posted: Sun May 02, 2010 4:26 pm Post subject: |
|
|
File association - ok, I think is working now
GIcable had just 1 ditto, so no issue here. I forgot to carefully read/absorb your description.
Bit strings, yes, I'd like them for learning, and I suspect Rob and Vicky will too - for real work. Switchable option is fine by me.
MitsubishiTV IRscope .ict files through Widget
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8357
came from Philips remote RC1445301/00B provided by Verizon FIOS. I randomly stumbled on their 2 setup codes and they surprised me. For all I know, Philips did it ok.
EDITED HOURS LATER
Proton-Mitsubishi is likely legit, see this
http://www.hifi-remote.com/forums/viewtopic.php?t=9885&highlight=mitsubishi+proton
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
| Back to top |
|
|
rct
Joined: 03 May 2010
Posts: 10
|
| Posted: Mon May 03, 2010 4:10 pm Post subject: Re: Automated analysis of IR protocols |
|
|
| mathdon wrote: |
Finally, it is not necessary to have a Widget in order to use this analysis as IRScope now has the ability to import signals in either Pronto or UEI Learned forms. |
This is very interesting stuff. I'd like to be able to use it but don't have an IR widget or pronto. Where can I find out more about IRscope's requirements for devices or the supported file import formats?
Is this page http://www.compendiumarcana.com/irwidget/ still relevant for IRscope 2.x ?
I see one of the import file types is a timing related format that sounds somewhat generic. Any place I can see a sample of what that file should look like or a description?
Ideally I'd like to get the Dangerous Prototype USB IR toy http://dangerousprototypes.com/2010/01/29/prototype-usb-infrared-remote-control-receivertransmitter/ to be able to work with IRscope.
Is IRscope 2.x ok to use input where the carrier has already been removed from an IR decoder or does it need to see the carrier?
Is the MiniPOV3 in the devices drop down, theone from [url]Adafruit.com[/url] with the hacked firmware described here: http://forums.adafruit.com/viewtopic.php?p=22251
Thanks.
--Rob |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Tue May 04, 2010 7:46 am Post subject: |
|
|
Yes, the hardware requirements have not changed.
| Quote: | | I see one of the import file types is a timing related format that sounds somewhat generic. Any place I can see a sample of what that file should look like or a description? |
Look at the screenshot at the top of this thread. The lines of numbers with alternate + and - signs are in a format accepted by the Timing List import option. The numbers are the durations of pulses (+ sign) and gaps (- sign) in microseconds in the demodulated signal. A Timing List must start with a + number and end with a - number. The signal may be split into Single, Repeat and (possibly) Extra parts, prefixed by these words and a colon, exactly as in the screenshot, or it may be a single list without any such prefix. You also need to give the carrier frequency in a box on the import form.
| Quote: | | Is IRscope 2.x ok to use input where the carrier has already been removed from an IR decoder or does it need to see the carrier? |
In "IR Widget Count" mode, the one normally used with the Widget, the hardware needs to see the carrier. I understand that "IR Widget Time" mode is for use with demodulated signals, ie when the carrier has been removed by the hardware, but I have no means of testing this. As I said above, the Timing List import format uses the timings of the demodulated signal and you give the carrier frequency separately. For most decodes the carrier frequency is irrelevant, so you can give any figure if you don't know it. It is used only to distinguish between protocols that are identical apart from the frequency used.
I have absolutely no idea what a MiniPOV3 is, nor what the Discrete Count mode does. The hardware and original software are due to Kevin Timmerman. All I have done is enhance the software in its use with the Widget, so there are some things, like these other modes, that remain a mystery to me.
I wish you luck on this one! As far as I am aware, the various modes such as Widget and MiniPOV are designed for specific hardware and will not work with anything else. I know this is true of Widget Count mode, I may be wrong about the other modes.
That's all I am able to tell you. If Kevin is watching this thread, he may be able to add to this, and to correct me if I've got anything wrong.
________________
Graham |
|
| Back to top |
|
|
garyb.ncc
Joined: 25 Jan 2010
Posts: 37
|
| Posted: Tue May 04, 2010 3:07 pm Post subject: |
|
|
| mathdon wrote: | | All I have done is enhance the software in its use with the Widget, so there are some things, like these other modes, that remain a mystery to me. |
On this note I would like to try and twist your arm a bit to support another device. I have been using a USB-UIRT for quite some time and it has the capability to capture raw timings. I have been playing with writing code to format the USB-UIRT timings in the ict file format. I've got it where it will work, but I do need to do a little cleanup. All I am currently doing is capturing the data with the USB-UIRT and saving it as an ict file. The best case scenario would be to select the USB-UIRT as an input device and handle the formatting internal to IRScope and use it just like a widget. I really think it would be quite easy to do. Why do it? Well there are probably thousands of USB-UIRT users that could benefit from IRScope - especially now with all the Pronto options. If you take a look at the linked I posted you will see that the USB-UIRT supports a wide gamut of software with lots of users.
Let me know what you think. You can contact me privately if you prefer.
_________________
Gary |
|
| Back to top |
|
|
garyb.ncc
Joined: 25 Jan 2010
Posts: 37
|
| Posted: Thu May 06, 2010 5:50 am Post subject: |
|
|
OK let's get the party started with this new tool (which is great by the way). I have an unknown protocol that will not decode. I do not have the device nor the OEM remote control. What I do have is learned Pronto that was learned using a USB-UIRT and emailed to me. The device is a U-Control Wall-E robot. I have imported all the Pronto codes into irscope, saved the ict files and summary file, and uploaded them here. You will see from the analysed timings that the A:20 value is actually something like D:4, F:8, F:8. However the leadout varies. There doesn't seem to be a pattern to the variation, such as maintaining frame length.
I would like to determine the IRP spec to use in MakeHex to create a possible list of all functions. Maybe discover some undocumented functions.
_________________
Gary |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Thu May 06, 2010 9:48 am Post subject: |
|
|
This is a pretty simple protocol.
Freq: 44 kHz
1: +1500 -500
0: +500 -1500
leadin: +6000 -2000
leadout: +2000 -unsure
fixed data: 4 bits
variable data: 8 bits (repeated twice)
Each learned button, except for the TURN button, repeated 3 times. The TURN button had just 1 occurrence. I don't know if this is just how they were learned. My assumption is that the signal would repeat for as long as the button is held, but will repeat a minimum of 3 times.
The OFF time for the leadout pair was all over the place, ranging from -46k for the shortest sample to -123k for the longest sample. Normally this would imply that it's an "off as total" situation, but that doesn't hold true with the data, so I don't know what the leadout OFF time should be.
Here's the binary data:
1: Joystick Forward
+6000 -2000 1010 11111110 11111110 +2000 -46500
2: Joystick Backward
+6000 -2000 1010 11111101 11111101 +2000 -46500
3: Ahead Button
+6000 -2000 1010 10101110 10101110 +2000 -87000
4: Turn Button (once only)
+6000 -2000 1010 10101100 10101100 +2000 -?????
5: Rotate Button
+6000 -2000 1010 10101101 10101101 +2000 -64000
6: Circle Button
+6000 -2000 1010 10101011 10101011 +2000 -123500
7: Light Button
+6000 -2000 1010 10100100 10100100 +2000 -59000
8: Music Button
+6000 -2000 1010 10100110 10100110 +2000 -79500
9: Dance Button
+6000 -2000 1010 10100101 10100101 +2000 -86000
10: Eyes Button
+6000 -2000 1010 10100111 10100111 +2000 -68000
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
rct
Joined: 03 May 2010
Posts: 10
|
| Posted: Thu May 06, 2010 10:36 am Post subject: Successfully using IRscope (manual import of timing string) |
|
|
| mathdon wrote: |
| rct wrote: | | I see one of the import file types is a timing related format that sounds somewhat generic. Any place I can see a sample of what that file should look like or a description? |
Look at the screenshot at the top of this thread. The lines of numbers with alternate + and - signs are in a format accepted by the Timing List import option. The numbers are the durations of pulses (+ sign) and gaps (- sign) in microseconds in the demodulated signal. A Timing List must start with a + number and end with a - number. The signal may be split into Single, Repeat and (possibly) Extra parts, prefixed by these words and a colon, exactly as in the screenshot, or it may be a single list without any such prefix. You also need to give the carrier frequency in a box on the import form.
|
Graham: Thanks for the very helpful response. I'm now using IRscope manually. I pasted in the timing for a Sony CD Stop IR command which I got from this blog post on Understanding Sony IR remote codes, LIRC files, and the Arduino library. IRscope seemed to perfectly analyze it and give a summary. From there I was able to save that signal in most of the formats that IRscope is outputting. Now I have starting point of a reference for the various file formats / code storage. (I wasn't able to do a Pronto decoded output because it was complaining that it couldn't find Sony IRP, which I'm guessing I'd need to download or create from some place to provide the base protocol info.)
To help anybody else who finds this thread and wants to try IRscope without having an IR widget, here's how:
* download IRscope and start it
* Click the import button
* In the import format radio buttons, select "Timing List".
* In the Frequency input box, enter 40000 (to represent 40 Khz)
* Paste the following string for a Sony CD Stop command as a single line:
| Code: | | +2400 -600 +600 -600 +600 -600 +600 -600 +1200 -600 +1200 -600 +1200 -600 +600 -600 +1200 -600 +600 -600 +600 -600 +600 -600 +1200 |
* Click Ok, you should now get a timing diagram in one window and the decoded IR command should show in the main IRscope window.
Hope This Helps,
--Rob |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Thu May 06, 2010 10:53 am Post subject: Re: Successfully using IRscope (manual import of timing stri |
|
|
| rct wrote: | | I wasn't able to do a Pronto decoded output because it was complaining that it couldn't find Sony IRP, which I'm guessing I'd need to download or create from some place to provide the base protocol info.) |
The IRP files can be found in the zip file containing the MakeHex program:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=5209
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
garyb.ncc
Joined: 25 Jan 2010
Posts: 37
|
| Posted: Fri May 07, 2010 5:25 am Post subject: |
|
|
| The Robman wrote: | | Each learned button, except for the TURN button, repeated 3 times. The TURN button had just 1 occurrence. I don't know if this is just how they were learned. |
Actually they were learned with no repeats if you look at the Pronto file. The default repeat for an irscope import is 3, so I just left it at that. The TURN button decoded in irscope like a macro with 3 decodes; so for this one I set the repeat to 1 for the import.
| Quote: | | My assumption is that the signal would repeat for as long as the button is held, but will repeat a minimum of 3 times. |
I think you are correct about how the button works based on the way a robot would typically work. One thing about the way a USB-UIRT learns is that the learn does not show the repeats. The repeat count is supplied in the Transmit function call to the device by the calling application. Generally a default repeat count of 4 works, but on some occasions you need more and some less. I'm not really sure what the actual OEM remote does as far as repeats.
| Quote: | | The OFF time for the leadout pair was all over the place, ranging from -46k for the shortest sample to -123k for the longest sample. Normally this would imply that it's an "off as total" situation, but that doesn't hold true with the data, so I don't know what the leadout OFF time should be. |
This is really the issue. Like I indicated, the idea was to be able to use MakeHex to generate Pronto for a range of functions. With the leadout off time the way it is, I not really sure how to write the IRP spec required for MakeHex.
_________________
Gary |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Fri May 07, 2010 7:24 am Post subject: |
|
|
| garyb.ncc wrote: | | The Robman wrote: | | The OFF time for the leadout pair was all over the place, ranging from -46k for the shortest sample to -123k for the longest sample. Normally this would imply that it's an "off as total" situation, but that doesn't hold true with the data, so I don't know what the leadout OFF time should be. |
This is really the issue. Like I indicated, the idea was to be able to use MakeHex to generate Pronto for a range of functions. With the leadout off time the way it is, I not really sure how to write the IRP spec required for MakeHex. |
What's the story with this device, do you know someone who has it that would be able to run some tests (ie, do they have a Pronto or some other means to test Pronto hex) ? If so, we could try standardizing the leadout time and have them test it to see if it works.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
garyb.ncc
Joined: 25 Jan 2010
Posts: 37
|
| Posted: Fri May 07, 2010 11:45 am Post subject: |
|
|
I do know someone with the device and he probably would run some test in Pronto format (to my knowledge he has no JP1 remotes). He is in poor health right now, so we can see if he is up to it if you have some suggestions. I don't have access to the remote since he lives 3 times zones away.
_________________
Gary |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
