Remot1 Remote Control Receiver Kit
I've sent an email to Mikkel on this subject and, figuring he is busy as usual, decided to post the subject here to see if anyone who has bought the Remote1 Kit can comment.
I bought the bare board with the processor, xtal, and caps only, populated most of the board from my surplus parts bin, soldered everything in and it worked the first time it powered up.
The remote used for testing is a One-For-All, OFA Kameleon, 6 device remote. This remote supports hundreds of models, including the Philips communication protocol supported by the Remote1. The pot is a 4 gang ALPs. I selected the TV device on the remote and the first of the 4 codes worked.
The movement of the pot however was not smooth when the volume control was pressed and held. The pot advanced slightly, stopped, then advanced again a bit, and then stopped. Pressing the volume button and quickly releasing produced a slight increment as expected. Just for confirmation, I checked a few other remote controlled components with the OFA remote and they worked smoothly so it appeared that the jerky pot movement was not related to the remote itself.
Still, thinking that the specific Philips device I selected might be the problem, I made a list of all the Philips devices supported by the remote that were likely to have volume control functions: 33 different codes. I programmed the remote for each of the 33 and 9 were recognized by the Remote1. They all exhibited the same jerky motion.
I connected a scope to the IR receiver and it appeared that the remote was sending two bursts of data, each burst is about 20 something mS long with a 70 something pause between the two, for each press of the button. A continuous string generated the two burst data packs, each about 70 mS apart. There were no detectable dropped commands out of the IR sensor. Both the remote and the IR sensor looked like they were working properly.
However, connecting the scope to the motor power showed that in response to a command, the motor was activated for about 200 mS, then was turned off for about 140 mS, (a 340 Ms or so cycle) even when a continuous string of commands was being sent. It would seem therefore, some commands in the string are ignored -- the motor turns off regardless of the succeeding command telling the Remote1 to turn/stay on. This on-off cycle to the motor when the command string was continuous seemed to be a problem.
Also, it appeared that occasionally the motor would skip more than just the commands during the cycle itself. When the button was continuously pressed the motor would occasionally stop for more than the 140 mS before it starts moving again. Very annoying and not what one would expect.
According to the schematic the IR sensor is read off INT0 suggesting that the micro should be reading each burst of data via an interrupt service routine -- unless however it is being turned off in software. I would expect that if the software detected a subsequent command to move it would simply extend the motor on-time another increment, not turn it off.
Of course I could be missing something not obvious to the untrained observe.
Any suggestions on how to address the jerky motion of the volume control would be appreciated.
I've sent an email to Mikkel on this subject and, figuring he is busy as usual, decided to post the subject here to see if anyone who has bought the Remote1 Kit can comment.
I bought the bare board with the processor, xtal, and caps only, populated most of the board from my surplus parts bin, soldered everything in and it worked the first time it powered up.
The remote used for testing is a One-For-All, OFA Kameleon, 6 device remote. This remote supports hundreds of models, including the Philips communication protocol supported by the Remote1. The pot is a 4 gang ALPs. I selected the TV device on the remote and the first of the 4 codes worked.
The movement of the pot however was not smooth when the volume control was pressed and held. The pot advanced slightly, stopped, then advanced again a bit, and then stopped. Pressing the volume button and quickly releasing produced a slight increment as expected. Just for confirmation, I checked a few other remote controlled components with the OFA remote and they worked smoothly so it appeared that the jerky pot movement was not related to the remote itself.
Still, thinking that the specific Philips device I selected might be the problem, I made a list of all the Philips devices supported by the remote that were likely to have volume control functions: 33 different codes. I programmed the remote for each of the 33 and 9 were recognized by the Remote1. They all exhibited the same jerky motion.
I connected a scope to the IR receiver and it appeared that the remote was sending two bursts of data, each burst is about 20 something mS long with a 70 something pause between the two, for each press of the button. A continuous string generated the two burst data packs, each about 70 mS apart. There were no detectable dropped commands out of the IR sensor. Both the remote and the IR sensor looked like they were working properly.
However, connecting the scope to the motor power showed that in response to a command, the motor was activated for about 200 mS, then was turned off for about 140 mS, (a 340 Ms or so cycle) even when a continuous string of commands was being sent. It would seem therefore, some commands in the string are ignored -- the motor turns off regardless of the succeeding command telling the Remote1 to turn/stay on. This on-off cycle to the motor when the command string was continuous seemed to be a problem.
Also, it appeared that occasionally the motor would skip more than just the commands during the cycle itself. When the button was continuously pressed the motor would occasionally stop for more than the 140 mS before it starts moving again. Very annoying and not what one would expect.
According to the schematic the IR sensor is read off INT0 suggesting that the micro should be reading each burst of data via an interrupt service routine -- unless however it is being turned off in software. I would expect that if the software detected a subsequent command to move it would simply extend the motor on-time another increment, not turn it off.
Of course I could be missing something not obvious to the untrained observe.
Any suggestions on how to address the jerky motion of the volume control would be appreciated.
Pogo,
Sorry I cannot help you, I ordered the switched attenuator unit and not the motorized pot.
I'm sure someone here will help you out, we are a great group of folks.
Good luck with the herky-jerky volume knob. Please inform us of the corrections made when you identify the issue.
Merry Christmas
Ron
Sorry I cannot help you, I ordered the switched attenuator unit and not the motorized pot.
I'm sure someone here will help you out, we are a great group of folks.
Good luck with the herky-jerky volume knob. Please inform us of the corrections made when you identify the issue.
Merry Christmas
Ron
My final quest for figuring what the problem is with the Remote1 was a test to see if the ALPs motorpot might be defective. I wired it up through a number of current limiting resistors to emulate the voltage drop across the control transistors and the motorpot worked smoothly all the way down to three volts.
I could be mistaken but after a bit more time excluding all the hardware, I'm convinced that the erratic pot motion is due to one or more software bugs.
The software turns the motor off when, in fact, the command string indicates that it should continue to be on. In addition, the software occasionally misses a command and the motor turns off for too long. This causes erratic motion when the volume control is pressed continuously.
Quite frankly, I didn't spend big bucks on ALPs motorpots (for a total of 12 channels) to wind up with such buggy operation. At least for my application this is unacceptable. For your application however this might be just dandy.
Here are some options:
1. Replace the Remote1 with another circuit available here:
http://stores.ebay.com/DIY-Gene
This might be a bit tricky for me since I am short on space in the enclosure.
2. Try a fix using some external logic: use a couple 4013 flip flops to latch to circuit's motor output, and use the output of the IR sensor plus a timer to bypass the software that shuts the motor down, plus some logic to make it all work without the motor overshooting the stop position. Very Messy.
3. Wait for a software fix which might not happen.
Any other suggestions?
One final comment: properly done RELIABLE real time software often makes extensive use of input and command buffers, task queues, task managers plus all the related pointers, counters, and timers, often all written in assembly. Obviously the usual manufacturers of commercial components with remote volume controls have this mastered. But as the Remote1 demonstrates, it is not a trivial exercise.
I could be mistaken but after a bit more time excluding all the hardware, I'm convinced that the erratic pot motion is due to one or more software bugs.
The software turns the motor off when, in fact, the command string indicates that it should continue to be on. In addition, the software occasionally misses a command and the motor turns off for too long. This causes erratic motion when the volume control is pressed continuously.
Quite frankly, I didn't spend big bucks on ALPs motorpots (for a total of 12 channels) to wind up with such buggy operation. At least for my application this is unacceptable. For your application however this might be just dandy.
Here are some options:
1. Replace the Remote1 with another circuit available here:
http://stores.ebay.com/DIY-Gene
This might be a bit tricky for me since I am short on space in the enclosure.
2. Try a fix using some external logic: use a couple 4013 flip flops to latch to circuit's motor output, and use the output of the IR sensor plus a timer to bypass the software that shuts the motor down, plus some logic to make it all work without the motor overshooting the stop position. Very Messy.
3. Wait for a software fix which might not happen.
Any other suggestions?
One final comment: properly done RELIABLE real time software often makes extensive use of input and command buffers, task queues, task managers plus all the related pointers, counters, and timers, often all written in assembly. Obviously the usual manufacturers of commercial components with remote volume controls have this mastered. But as the Remote1 demonstrates, it is not a trivial exercise.
Hello Mikkel.
I just happened across this thread and when I saw your website I thought 'my prayers are answered!' 🙂
I have a commercial Amp which I'm looking to modify/upgrade. Unfortunately one of the biggest barriers to sound quality is the input selection which is currently taken care of by a TC9163AF micro switch array. Ive been looking into ways to change this to relay switching while keeping the full remote facility and retaining the amplifiers functionality.
In your website you say "You can also use your own controller - complete information is in the manual". Does this mean there is a possibility that the Input 1 kit could be controlled by the existing front panel hardware in my amp? (The microprocessor is a PIC16F72-I/SP. There are 5 inputs and a tape monitor).
I have full scematics for the Amplifier which I can email to you. Would you mind taking a look please?
Rgds,
Mike.
I just happened across this thread and when I saw your website I thought 'my prayers are answered!' 🙂
I have a commercial Amp which I'm looking to modify/upgrade. Unfortunately one of the biggest barriers to sound quality is the input selection which is currently taken care of by a TC9163AF micro switch array. Ive been looking into ways to change this to relay switching while keeping the full remote facility and retaining the amplifiers functionality.
In your website you say "You can also use your own controller - complete information is in the manual". Does this mean there is a possibility that the Input 1 kit could be controlled by the existing front panel hardware in my amp? (The microprocessor is a PIC16F72-I/SP. There are 5 inputs and a tape monitor).
I have full scematics for the Amplifier which I can email to you. Would you mind taking a look please?
Rgds,
Mike.
Re: Remot1 Remote Control Receiver Kit
I took a couple of days off for Christmas 🙂
It sounds like the data packets are transmitted to close together. There should be a 85ms pause between commands (according to the Philips docs). This probably means that some of the packets are being dropped by the controller.
It is a problem. The on time of 200mS is correct, but the long off time isn't correct.
That way would be ideal - but an extra timer would be needed for that. I am working on a different IR detection routine that would free-up a timer. If that works out, the software should be ready next week...
Best regards,
Mikkel C. Simonsen
x-pogo said:
I took a couple of days off for Christmas 🙂
It sounds like the data packets are transmitted to close together. There should be a 85ms pause between commands (according to the Philips docs). This probably means that some of the packets are being dropped by the controller.
It is a problem. The on time of 200mS is correct, but the long off time isn't correct.
That way would be ideal - but an extra timer would be needed for that. I am working on a different IR detection routine that would free-up a timer. If that works out, the software should be ready next week...
Best regards,
Mikkel C. Simonsen
mikesnowdon said:
Just send them, and I'll have a look. Looking at the TC9163 schematic, I think it should be possible to hook-up.
Best regards,
Mikkel C. Simonsen
Telstar said:
Yes and no 🙂
How do you want to control it? If you use "analog" control, you could simply use a motorised pot. If you want digital control, you would need matched/pre-selected LDRs also. I have written "lightspeed" software for the VolControl2.
Best regards,
Mikkel C. Simonsen
mcs said:
Hi Mikkel,
I dont know which way to choose, but i know that i want very fine steps, less than 1dB ideally. Optionally with 7lines display.
The starting unit would be george one, which a has matched pair, i would open the box and put it in a bigger chassis, where it would sit the control psu and the eventual display.
Mail me more details and pricing if you wish.
Telstar said:
You are talking about the standard unit with 4 LDRs I guess? You could control it with the Control2 board, special software and an extra chip. You can get steps smaller than 1dB also. But you would have to store the settings yourself, as the LDRs are all different.
But if you have two multimeters and some patience, it's possible 🙂
Best regards,
Mikkel C. Simonsen
mcs said:
I'm talking about the lightspeed mk2, with stereo volume control. i guess u are right that there are 4 LDR total in it, but i though that they were matched, at least 2 by 2.
Regards
Telstar said:
Do you have a direct link to a description? I don't feel like reading through a 60+ page thread 😉
They may be matched, but to get 0.5dB or 1dB steps, you will have to calibrate the controller to the LDRs. The matched LDRs will make it much easier to get good channel tracking of course.
Best regards,
Mikkel C. Simonsen
Hi Mikkel.
Any news on my enquiry yet? You were going to look at the connection of the TC9163 to the Input1 board for me.
Cheers.
Mike.
Any news on my enquiry yet? You were going to look at the connection of the TC9163 to the Input1 board for me.
Cheers.
Mike.
I think the LDRs are matched in the original design. However, it is very very difficult in getting matched pairs especially in balanced setup. Using microcontroller allows closer tracking.
But the language for microcontroller is not easy. If mcs can make is easier for use, that would be wonderful!
But the language for microcontroller is not easy. If mcs can make is easier for use, that would be wonderful!
ackcheng said:
I asked George and pointed him to this thread.
I dont use balanced... let's see what can be done 🙂
Mikkel,
I have finished building the Control1 combined with the Input4 and could not be more pleased with the quality of the kits. The boards were well thought out and professionally layed out. Very good Job!
Being a newbie to electronics in general ( and I mean newbie) if I can build these sucessfuly anybody can. I tested the boards as directed in the manual prior to inserting the spider chips (controllers), everything works as expected so I finished the builds and tested the relays with the Control1 front panel attached through the ribbon cable. Lights worked and relays made noise. I am stuck at this point. Solder monkey I am.
As I stated in an earlier post, the documentation is somewhat sparce for a newbie like me. I have a couple of questions on how to connect the preamp outputs on the Input4 board.
On page 4 of the manual, under Connection Headers it states;
" JP9-12 are used for connecting a linestage and/or volume control. JP11 and 12 are outputs and JP9 and 10 are inputs."
Are these "JP9-10" pinouts used as a jumper block? or as (wire) connection points for preamp left and right channels?
There are 4 RCA type jacks on the back of the unit, and none of them are labeled in the manual or the schematic. ( I tried to understand the schematic but I'm too newb.) The Input4 Introduction states; "This circuit is input selector with three inputs and mute. There are also outputs for a power relay and an additional relay." If only 3 of the 4 RCA jacks are inputs is the 4th one the output? If so which one? Or was it designed to be built into an amplifer and not a stand alone Input switched box?
Sorry for the dumb questions, I tried to figure this out all day before I asked........
Pictures tomorrow.
Ron
I have finished building the Control1 combined with the Input4 and could not be more pleased with the quality of the kits. The boards were well thought out and professionally layed out. Very good Job!
Being a newbie to electronics in general ( and I mean newbie) if I can build these sucessfuly anybody can. I tested the boards as directed in the manual prior to inserting the spider chips (controllers), everything works as expected so I finished the builds and tested the relays with the Control1 front panel attached through the ribbon cable. Lights worked and relays made noise. I am stuck at this point. Solder monkey I am.
As I stated in an earlier post, the documentation is somewhat sparce for a newbie like me. I have a couple of questions on how to connect the preamp outputs on the Input4 board.
On page 4 of the manual, under Connection Headers it states;
" JP9-12 are used for connecting a linestage and/or volume control. JP11 and 12 are outputs and JP9 and 10 are inputs."
Are these "JP9-10" pinouts used as a jumper block? or as (wire) connection points for preamp left and right channels?
There are 4 RCA type jacks on the back of the unit, and none of them are labeled in the manual or the schematic. ( I tried to understand the schematic but I'm too newb.) The Input4 Introduction states; "This circuit is input selector with three inputs and mute. There are also outputs for a power relay and an additional relay." If only 3 of the 4 RCA jacks are inputs is the 4th one the output? If so which one? Or was it designed to be built into an amplifer and not a stand alone Input switched box?
Sorry for the dumb questions, I tried to figure this out all day before I asked........
Pictures tomorrow.
Ron
mcs said:
See last posts 🙂
http://www.diyaudio.com/forums/showthread.php?s=&postid=1697604#post1697604
mikesnowdon said:
Hi Mikkel.
Any updates to my inquiry please? Are my emails getting though the spam filter?
Mikkel,
Forget my last question, I figured out JP11 & JP12 are the output pins (like it says in the manual) Duh.... Said I was a newb.
Thanks anyway..........I know you are busy.
One question though, What is the 4th input for? It has a different set of resistor values than 1 - 3 ? Phono?
Thanks
Ron
Forget my last question, I figured out JP11 & JP12 are the output pins (like it says in the manual) Duh.... Said I was a newb.
Thanks anyway..........I know you are busy.
One question though, What is the 4th input for? It has a different set of resistor values than 1 - 3 ? Phono?
Thanks
Ron