Here is a little start. I have decided to use LED indication for level from 0dB -60dB in 10dB jumps. But i am open to others opinion.
What i need to know is (That was is missing on the control schematic besides PSU):
Which type of control for level. Buttons or encoder?
Which standard of RC5 decoder .. Philips? Maybe i will do a remotecontrol also!?
Sonny
What i need to know is (That was is missing on the control schematic besides PSU):
Which type of control for level. Buttons or encoder?
Which standard of RC5 decoder .. Philips? Maybe i will do a remotecontrol also!?
Sonny
Attachments
I'd vote for a rotary encoder.
Also, RC5 is good; you could just buy a universal remote and be up and running - right?
cool 🙂
mlloyd1
Also, RC5 is good; you could just buy a universal remote and be up and running - right?
cool 🙂
mlloyd1
sonnya said:Here is a little start. I have decided to use LED indication for level from 0dB -60dB in 10dB jumps. But i am open to others opinion.
What i need to know is (That was is missing on the control schematic besides PSU):
Which type of control for level. Buttons or encoder?
Which standard of RC5 decoder .. Philips? Maybe i will do a remotecontrol also!?
Sonny
One thing about the microcontroller and the RC5 reciever. It will not be possible to turn the microcontroller. completly off when using RS232 (no hardware handshake) or RC5.
The micro needs 16mSec. to turn on from "Power Down", but the software and PCB can be made in such a way, that you will not get any (or Very little!) radiation from the micro and crystal.
Secondly The CPU can turn the most internal parts off without going into PowerDown. In this mode (idle mode) it can wakeup in two clockcycles.
It was my intention to use a standard remote.. But also to make one later.
Sonny
The micro needs 16mSec. to turn on from "Power Down", but the software and PCB can be made in such a way, that you will not get any (or Very little!) radiation from the micro and crystal.
Secondly The CPU can turn the most internal parts off without going into PowerDown. In this mode (idle mode) it can wakeup in two clockcycles.
It was my intention to use a standard remote.. But also to make one later.
Sonny
I'm imagining that doing what some of the other manufacturers do could cut down on radiation: put the micro/display board immediately parallel to the front panel and the audio circuitry parallel to the bottom of the case, close to the in/out jacks as you can. A number of good CDplayer design do this. The latest Mark Levinson preamp puts the analog signal handling stuff in one box and everything else in another. Looks weird, but kinda makes sense for minimal contamination.
mlloyd1
mlloyd1
I am going to make a ground shield, place the SMD part on the bottomside closest to the chassis.
The design i have made i have only seen some contamination on the supply voltage, but then also have somthing like 90% ground on those doublesided board.
It have been a little undecided .. Should i make a frontpanel board as with CD playes with the controlpart on it or should i place it all on one board?
I have decided to try make both types, to see/measure and hear how they behave.
Sonny
The design i have made i have only seen some contamination on the supply voltage, but then also have somthing like 90% ground on those doublesided board.
It have been a little undecided .. Should i make a frontpanel board as with CD playes with the controlpart on it or should i place it all on one board?
I have decided to try make both types, to see/measure and hear how they behave.
Sonny
Sonny,
I do not know exactly what you are building, but if possible use a controller which has a sleep mode. I used the PIC 16F84 for my preamp.
During normal operation it is in sleep mode and the clock is switched off by the micro. With a RC5 remote i can wake it up and it performs it's task (switch on, volume up, etc). After that i goes to sleep again and there is NO interference.
Have a look at my site, you can download some code for receiving RC5.
Greetings,
Guido
I do not know exactly what you are building, but if possible use a controller which has a sleep mode. I used the PIC 16F84 for my preamp.
During normal operation it is in sleep mode and the clock is switched off by the micro. With a RC5 remote i can wake it up and it performs it's task (switch on, volume up, etc). After that i goes to sleep again and there is NO interference.
Have a look at my site, you can download some code for receiving RC5.
Greetings,
Guido
How fast does the pic start the oscillator... For the Atmel AT89s8252 the time is 16msec. So if you send a single command over RC5 or RS232 you will loose som data. For Rs232 at 9600 baud you will loose something like 15 - 16 bytes of data. Thats something i cannot live with.
Without communication this will not be a problem because of debounce in a encoder or a key . And the human reactiontime.. It will not be noticed.
But if the PIC can do the job in 1 msec.. I would consider a PIC instead.
Sonny
Without communication this will not be a problem because of debounce in a encoder or a key . And the human reactiontime.. It will not be noticed.
But if the PIC can do the job in 1 msec.. I would consider a PIC instead.
Sonny
Hi,
Saw your post on the other forum after this one. You are using a micro which also can stop the clock. Excellent! Guess i now comes down to what you are used to. With the pic there is less IO, but i am using I2C IO chips to solve that problem.
The pic micro is indeed too slow in waking up to decode the first RC5 frame. But i am using an universal philips remote and it continuously sends frames (part of the RC5 spec i think).
So i skip what is left of the first one and decode the second frame.
Since we are talking msec here, that's no problem.
As you can see on my site i am (still) using a motor-pot. Probably not the best solution but maybe i am going to try a digital one later.
Guido
Saw your post on the other forum after this one. You are using a micro which also can stop the clock. Excellent! Guess i now comes down to what you are used to. With the pic there is less IO, but i am using I2C IO chips to solve that problem.
The pic micro is indeed too slow in waking up to decode the first RC5 frame. But i am using an universal philips remote and it continuously sends frames (part of the RC5 spec i think).
So i skip what is left of the first one and decode the second frame.
Since we are talking msec here, that's no problem.
As you can see on my site i am (still) using a motor-pot. Probably not the best solution but maybe i am going to try a digital one later.
Guido
Hi guido, You are right ... After i posted my last message i was thinking of that to... RC5 does continue to send data when you hold a key down.. So this would not be a problem..
It will only be a problem with RS232 without hardware handshake.
By the way.. The "/PFO" pin from the watchdog will be used to store data just before total powerloss. The AT89 has 2Kbyte EEprom to store data in.
Sonny
It will only be a problem with RS232 without hardware handshake.
By the way.. The "/PFO" pin from the watchdog will be used to store data just before total powerloss. The AT89 has 2Kbyte EEprom to store data in.
Sonny
- Status
- Not open for further replies.
- Home
- Source & Line
- Digital Source
- Control part for PGAXXXX/WM8816