Oh man, i given you troubles
It's actually easy to redo but you're going to need to mount the surface mount pieces on the bottom.
Thanks , Jeff. Now I can archive and have a close representation of what
my two v3.3 boards are.
I see the backwards C11/14 - C12/16. Another option here would be a 47u -
35-50V NP (polarity would not matter).
That protected supply looks nice. Would be good for development.
OS
I've got a pair of those protected supplies waiting to go into my sub amps.
Uno ceramic resonator
Uno uses a low cost ceramic resonator for the clk. The resonator does not have the accuracy/stability for USB so the USB interface includes a crystal. If accurate timing is required from an Arduino, use a Leonardo or Mega with a crystal clk. Leonardo also has on chip USB. Atmega XTAL/resonator settings in the boot code.
Uno uses a low cost ceramic resonator for the clk. The resonator does not have the accuracy/stability for USB so the USB interface includes a crystal. If accurate timing is required from an Arduino, use a Leonardo or Mega with a crystal clk. Leonardo also has on chip USB. Atmega XTAL/resonator settings in the boot code.
I've been wondering about the crystals I selected on the latest board. I used one from the Nano design. Something is causing inconsistent communications. That's likely it. I'll see it I can connect a better crystal to the prototype and test again.
It seems a lot of the recommended software tools don't work the best with Windows 7. Atmel's Flip tool can't find a bunch of .dlls needed to load usb firmware on the 16U2. It's not as easy as with XP where you just dump them in the system32 folder either. When I have a parallel bootloader connected to the Atmega328 with the USB cable connected as power, Windows sees the 16U2 in the device manager and loads drivers. When I disconnect the parallel loader and try to connect via USB it doesn't see it. The fun continues.
Oh, yes
By the way... just in parallel... thought we could add an enhancement for high-power pro-grade systems. I mean - a bit more heat management, adding a rather slow, low noise fan and using one output control channel for managing it without any serious board modifications.
Algorithm can be rather simple - as soon as one of the thermal sensors triggers, the firmware switches the fan om and starts the virtual timer. If the sensor returns to initial "cold" state within, say 1 minute, we run the fan for 3 minutes more and switch it off. If it doesn't - we shut down the amp.
A higher quality option would utilize analog temperature measurement and more precise fan control (e.g. PWM), so that the whole thing provides more reliable regulation and shuts down only if the situation goes really bad.
What do you think?
By the way... just in parallel... thought we could add an enhancement for high-power pro-grade systems. I mean - a bit more heat management, adding a rather slow, low noise fan and using one output control channel for managing it without any serious board modifications.
Algorithm can be rather simple - as soon as one of the thermal sensors triggers, the firmware switches the fan om and starts the virtual timer. If the sensor returns to initial "cold" state within, say 1 minute, we run the fan for 3 minutes more and switch it off. If it doesn't - we shut down the amp.
A higher quality option would utilize analog temperature measurement and more precise fan control (e.g. PWM), so that the whole thing provides more reliable regulation and shuts down only if the situation goes really bad.
What do you think?
Oh, yes
By the way... just in parallel... thought we could add an enhancement for high-power pro-grade systems. I mean - a bit more heat management, adding a rather slow, low noise fan and using one output control channel for managing it without any serious board modifications.
Algorithm can be rather simple - as soon as one of the thermal sensors triggers, the firmware switches the fan om and starts the virtual timer. If the sensor returns to initial "cold" state within, say 1 minute, we run the fan for 3 minutes more and switch it off. If it doesn't - we shut down the amp.
A higher quality option would utilize analog temperature measurement and more precise fan control (e.g. PWM), so that the whole thing provides more reliable regulation and shuts down only if the situation goes really bad.
What do you think?
Cool. A suggestion .... with D12/13 as bicolor led , D4 is free and unbuffered
and can be on/off. Unfortunately , only D3/5/6/9/10/11 can be PWM.
But , why be "anal" ? A simple on/off for a big fan with the thermal alarm
would accomplish the goal.
Your "virtual timer" idea would work well. The reason I mentioned this is
that both my V3.3 Wilhelm boards have a "free" pin 6.
Your "pro" idea , scaling the PWM to a analog sensor would be good for
my new 700W 5 pair MT-200 OPS
. OS
Nano uses a three pin ceramic resonator same as the Uno. Micro uses a crystal same as Leonardo, which has four pads and requires 2 Cs and an R. Zoom in on the pics here: Arduino - Products
The FT232R FTDI chip used on the Nano has an internal 12 MHz oscillator that is used for USB, X4 to 48 MHz for USB DPLL, and is USB certified so its clk shouldn't be an issue. However, for use of it's internal oscillator, FTDI Vcc min = +4.0V. See data sheet par 7.6 for use of external osc or Vcc = +3.3V.
Here's a BOM. It wouldn't be complete without a couple stupid mistakes in the silk. C11 and C12 orientation is backwards.
Hi Jeff ,please look at the bom.What do you mean 108uf?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.