none

I would like to bump this up as I would like to archive a whole project thread (in my case: http://forum.43oh.com/topic/695-consumer-ir-cir-capture/). It seems the board software has changed to "Community Forum Software by IP.Board", a short tutorial on how to enable those links is given at http://invisionmodding.com/tutorials/article/527-print-send-download-links-in-topic-view/ Note that I am not familiar with this software, I only know that the URI parameters are not effective on this current installation. I'd appreciate if you could look into this again.

Thanks for the code in the first post, however, it seems you are using the (weak) high-z state for the clock signal.

If the motor can be reliably controlled at different speeds, probably even the regular tick motion could be created (although more silent), and thus also the irregular tick. But currently, stopping and starting the motor will cause step-loss which of course is not an option. If this can't be overcome, i.e. the motor needs to keep running as fly-wheel, indeed only an irregular sweep is feasable, but I think this still may be interesting to notice.

Since the clockwork I am working with is a continuous type ("sweep movement"), it needs an 8 Hz waveform to move 1 s, and I'm currently trying to figure out how to actuate it properly with the irregular timing. Also I noticed that the stator seems to be slightly magnetized (to determine the rotation), as the same timing for both polarities causes different motion. I was looking at different "Vetinari" clock projects and found another, minimalistic approach using an MSP430G2211: http://renaud.schleck.free.fr/horloge_vetinari.php He does not use a sequencer but randomly varies the length of t

Just to complete this with some references and forgotten information regarding the update: 43oh blog entry: http://www.43oh.com/2011/04/msp430-launchpad-firmware-update-2-0-released/ 43oh forum thread: http://forum.43oh.com/topic/503-launchpad-firmware-update/ You could even use another Launchpad as USB-serial interface (maybe even with standard 9600 baud or using the default configuration of the TUSB3410): http://forum.43oh.com/topic/2568-speeding-up-the-launchpad-uart/?hl=tusb3410#entry21487 Regarding the firmware (http://www.43oh.com/2011/04/msp430-launchpad-firmware-update-2-0

I've posted information on how to "easily" fix a Launchpad with failed firmware update (requires a 3.3 V serial interface, e.g. a 2nd Launchpad): http://forum.43oh.com/topic/4622-recover-the-mps430-launchpad-from-failed-firmware-update/

When the Launchpad was quite new, TI published an Launchpad update program that would make it work with new (at the time) microcontrollers. But sometimes, the update failed, leaving me and others with a useless launchpad. http://processors.wiki.ti.com/index.php/MSP430_LaunchPad_Firmware_Update (BEWARE!) This has been discussed here (43oh.com) and elsewhere http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/p/97931/346074.aspx#346074 and someone in that thread was kind enough to backup his/her Launchpad's firmware: http://e2e.ti.com/cfs-file.ashx/__key

Bypassing the filter improves things slightly, but the MSP pulls the 1 mV signal (no current) up to 20 mV . I'll have to reduce sampling or try a buffer.

This is only noticeable when continuously converting (as configured above or single conversions retriggered in interrupt). A 10 k pot set to 750 mV is pulled up a few mV and gets a lot of noise (3 mV -> 133 mV peak to peak). My guess is that the ADC is charging up the filter cap and the driver output has no chance to sink the extra voltage through the 10k filter resistor (btw, the parts have the right values). So buffering or bypassing the filter may work?

I'm trying to measure load current controlled with TI DRV8801 (http://www.pololu.com/catalog/product/2136) with a Launchpad Rev. 1.5 and MSPG2231 using this code #define CURRENT BIT1 ... // start adc //ADC10CTL0 &= ~ENC; // Disable ADC ADC10AE0 = POS | CURRENT; ADC10CTL0 = ADC10SHT_2 // sample-and-hold time (64) + MSC // "sequential conversion"? //+ REF2_5V // //+ REFON // + ADC10ON // ADC on + ADC10IE // ADC interrupt enable ; ADC10CTL1 = INCH_1 // Channel //+ ADC10SSEL_3 // SMCLK /

Closer to three weeks now, but no update.. We

I could not get the symlink to work for another project.. Note that you should not rename a project directory outside CCS4. If the project is not found inside the 'remote' location, try to change the workspace there, and import and rename the project. While I am not able to symlink this project dir to the standard workspace, at least I can work on the project!

I generally organize project code independent from the tools used to create them, along with other documentation such as datasheets, notes, photos, etc. With TI's Code Composer Studio 4, this is unfortunately not simply a matter of opening a project file in an arbitrary location. All projects are stored in "the workspace", most likely set up in "My Documents". My first internet search brought up http://processors.wiki.ti.com/index.php ... e_Projects . I did not want to recreate a project in order to move it to a different place. If you are using Windows 7, symlinks* seem to be a method

I failed to grasp that TimerA has two CCUs, which allows for independent PPM capture and generation. The only important part is to read/compute/write the new CCR values in time. The other thing is that the demultiplexer reset needs to be controlled by the microcontroller, too, in order to be able to output channel signals even if there is no valid input signal (failsafe), as the reset pulse (on my receiver) depends on the reception as well. It is easily generated along with the ouput frame.

As it turns out, the TC4017BP responsible to separate the PPM signal into pulses for each channel is reset every frame (about 20 ms), so the modified PPM needs to be synchronous to the original signal (just one frame later). Although I have tried to keep calculations in pin- and timer interrupts to a minimum (by setting flags and crunching numbers in the main loop instead), they take long enough to cause problems when overlapping, i.e. an edge of the incoming signal concurs with an edge of the generated signal, causing jitter. Is there any way to prevent this, without moving the output af