Author Topic: Borderlands style jewelry box research thread (Read 12048 times)

Youkai · « **Reply #25 on:** September 12, 2018, 05:50:33 pm »

I don't think I can do the 3 wire configruation Ian.M because I need to have it connected to Arduino. Does this diagram look correct to you?

EDIT: I'm sure I didn't draw the interaction between the LED and the transistor correct there. Would I just draw that as if it were a wire?

Ian.M · « **Reply #26 on:** September 12, 2018, 07:31:45 pm »

That should work, (as long as you don't mix up the transistor emitter and collector) active high when the gap is *NOT* blocked.

If you make it active low, by putting the transistor between the Arduino input and Gnd with the 10K resistor as a pullup, you can do three wire.

The usual LED symbol has two parallel arrows to represent light.

Youkai · « **Reply #27 on:** September 12, 2018, 09:12:32 pm »

I re-drew the diagram. Does that look correct?

I just bend the two pins together and solder one wine to both of them and use that as the ground?

So in this configuration the Arduino pin will read high (5v) through the 10k resistor when the LED is blocked. Then when it's clear it will read low (0v, or close to it) because the path to ground has much lower resistance. Is that correct?

Ian.M · « **Reply #28 on:** September 12, 2018, 10:16:03 pm »

Nearly - you are missing the arrow that indicates the phototransistor emitter and that its NPN. Assuming you've got te emitter at the bottom, the circuit looks OK.

If you find it difficult to get a good logic '1' level (>4V) when the gap is blocked, due to stray light or an interruptor that isn't totally opaque, decrease the 10K resistor. Don't go below 2K.

Youkai · « **Reply #29 on:** September 12, 2018, 11:05:52 pm »

Ah, so like this? https://learn.parallax.com/sites/default/files/content/shield/robo_ch6/series_sch.jpg The two arrows outside indicate that it's a phototransistor and the one inside indicates the emitter?

Cool beans. I'll wire up a test circuit with my breadboard tonight if I have time.

Ian.M · « **Reply #30 on:** September 12, 2018, 11:46:06 pm »

Yes, that link has a good symbol. You'll also see ones with a base lead, most often in opto-couplers.

If you have problems identifying the pin numbers of your opto-sensor, find the anode and cathode of the LED using a DMM with a diode test range that goes up to 2V, then match that up to the diagrams in the datasheet.

Youkai · « **Reply #31 on:** September 13, 2018, 02:17:16 am »

I was able to get it working. Soldered the sensor according to my diagram and using a serial monitor was able to detect when the sensor was blocked or not in Arduino studio. Yay! one more hurdle down.

Youkai · « **Reply #32 on:** September 18, 2018, 10:26:47 pm »

I have tested the sensor and the button I'm going to use to open/close the thing. So now I'd like to start working on a more complete circuit diagram. But I'd like to do it in a program so I can quickly make adjustments to it without having to re-draw the whole circuit. I'm looking for a good simple editor that I can use to draw a circuit. I don't really need any fancy simulation or anything. I have LTspice and DipTrace on my computer and I'm having trouble getting them to do what I want. I'm sure that it's due to a profound lack of experience with these programs.

Does anybody have suggestions for a simple circuit diagram tool or a good tutorial that can show me how to use the ones I have?

EDIT: I'm starting to have some luck with DipTrace. I'll keep working with that for now and see if I can come up with something reasonable.

Youkai · « **Reply #33 on:** September 19, 2018, 01:19:06 am »

Ok so here is my first shot of a schematic. I made it using DipTrace. This is a schematic of a setup that I have wired successfully (though with only one RGB LED in my test). Pressing the button triggers the lights to turn on. Pressing it again turns them off.

Any input on the schematic would be appreciated. The next step is to expand the schematic to include the phototransistor and servos.

Nominal Animal · « **Reply #34 on:** September 19, 2018, 03:02:05 pm »

I just received a couple of small geared stepper motors, similar to these. The axial cross section is 10mm × 12mm, body length about 20mm, so it fits inside a 20mm tall cylinder with 16mm diameter or greater (not including wall thickness). The ones I have have a 1:275 gearbox and 18 degrees per step, i.e. 5500 steps per turn. I haven't tested mine yet, but I do believe they have enough torque to rotate the tray or open the lid directly, without any additional gearing. Forcing the trays (by hand) is likely to strip the metal gears. There is a little bit of backlash.

The ubiquitous 28BYJ-48 geared stepper motors have more torque, and since their diameter is 28mm, you could place those too inside your cylinders. However, their axis is 8mm off center, so you cannot fit them inside a 40mm diameter cylinder with the axis at the center.

Youkai · « **Reply #35 on:** September 19, 2018, 11:50:36 pm »

I revised my drawing. Made a couple custom components to help me out.

I included the RGB LED strip and the transistors/resistors into a component.
Made a component of the Photo-transistor switch with the 3-wire setup.
Made a stupid simple "Servo" because I couldn't find one in the components.
My button has a built in LED/resistor which is independent of the switch (4 wires) so I made that a component too.
I just used a stock multi-pin component for the Arduino. I might make a custom arduino component in the future so I can actually plan the wire placement.

Diagram is still missing the Buck converter. Also The arduino isn't going to have enough PWM pins so I'll need to include a PWM chip at some point. Probably something else I'm forgetting but I think it's pretty close to complete.

Please review and provide feedback on the diagram. I'm sure I'm breaking all sorts of best practices. Thank you!

Youkai · « **Reply #36 on:** September 22, 2018, 07:13:47 pm »

I think this is a complete schematic at this point. I'd really like some feed back. Primarily I have read that the TLC5940 can't handle that much current. Is there any reason to believe running this setup will burn out the chip?

I'm using Yellow as my positive wire color because I have RGB LED's and I want the led wire to be the color of the LED. Other than that the wire colors don't mean anything.

EDIT: Haha. I'm an idiot. The "Sensor" data pins need to go to the Pro Micro. Not to the TLC. Updating the diagram.

Youkai · « **Reply #37 on:** September 23, 2018, 05:27:22 am »

Found the issue with the sensors. Also found I was missing a wire for the button. This diagram has the updates.

Ian.M · « **Reply #38 on:** September 23, 2018, 07:00:49 am »

I think its going to be sub-optimal running both the LEDs and the servos from the TLC5940, as that will cause excessive flicker. A Futaba compatible servo signal requires a 50Hz repetition rate, and as the TLC5940 PWM timebase is common to all channels, that would force you to use 50Hz for the LED PWM frequency.

As ATmega328P based Arduinos have six hardware PWM pins, you should be able to connect the servo direct to the Arduino so you can run the LED PWM much faster, avoiding any perceptible flicker.

Youkai · « **Reply #39 on:** September 23, 2018, 08:28:19 pm »

Quote from: Ian.M on September 23, 2018, 07:00:49 am

As ATmega328P based Arduinos have six hardware PWM pins

The Pro Micro uses a ATmega32U4 which only has 5 PWM pins. I guess I need to do a test with the TLC5940/Sevo/LED and see how noticeable the flicker is. If it's bad I will need to consider not having the fade effect, maybe it's better with just setting a sold color; or using my Arduino Uno instead of the Pro Micro since that has 6 PWM pins.

Is there any good way for me to know/see the PWM repetition rate for a pin? How can I tell if it's using the standard or the 50hz?

EDIT: I'm also reading this stuff about DCPRG and whether it should be tied to HIGH or LOW. I guess the difference has something to do with the EEPROM value of 63, or not. I really don't understand it though. Can someone give me the ELI5 version? Do I just tie it to GND and not worry about it?

Youkai · « **Reply #40 on:** September 23, 2018, 09:22:03 pm »

Arg. Looking at the Arduino TLC library it seems that you can't change the pin numbers used. Which means I can't change the pin numbers for the Pro Micro. Sparkfun does have a library for their breakout but I'm not sure if that will work. I guess with this and the servo issue I'm back to using the UNO as my microcontroller.

EDIT: Well hell. The wiring diagram for the TLC library does not have configurable pins and connects to 4 PWM pins. Maybe a different library only uses 3? I'm confused.

EDIT 2: I guess I can change the pin numbers if I edit the library files. But I don't know which ones are required to be PWM pins so I can't safely change them. I assume all 4 that are assigned to PWM pins must be. Otherwise why would the developer of the library use up a PWM pin?

exuvo · « **Reply #41 on:** September 25, 2018, 04:20:18 pm »

You could ignore the arduino PWM library and configure the PWM peripheral yourself. Also never look for reason in those libraries, there is little to be found.
Find the datasheet for the microcontroller, the sections of interest are the Timers and what pins they allow for output compare / PWM. Each timer should have 2 output pins that are suitable for PWM. Usually you set the pin for output mode like normal, setup the TCCRx registers with a suitable output compare mode and prescaler (for frequency) and load OCRx with a value for length of pulse.

You might need to be careful with timer 0 as i think arduino likes to use it for the time keeping functions. If you wont be using those functions you can re-configure the timer for your own use or try to work with whatever frequency it is already running at.
The difficult part is usally finding a picture that shows what arbitary number an arduino pin is mapped to in the hardware, ex arduino pin 5 to PORTA bit 6.

Some example code from one of my ATmega328 projects if you find it helpful. Comments might be incorrect.

Code: [Select]

void TimersInit() {
	GTCCR = _BV(TSM) | _BV(PSR10); // pause timers
//	OCR0A = 0;

	//timer 0 - CTC toggle - output pulse 500kHz
	TCCR0A = _BV(WGM01);

	//timer 0 - prescale factor 8 - 1MHz
	TCCR0B = _BV(CS01);

	//122 full 4096 cycles / s


	OCR1A = 4096*2+1;//timer 0 takes 2 cycles for each pulse, first pulse is ignored. +1 to edge align with timer 0
//	OCR1B = 0;

	//timer 1 - Fast PWM
	TCCR1A = _BV(WGM11) | _BV(WGM10);

	//timer 1 - prescale factor 8
	TCCR1B = _BV(WGM13) | _BV(WGM12) | _BV(CS11);

	//122Hz full cycles

	GTCCR = 0; // resume timers
}

//timer compare to pin
#define TIMER0A 6
#define TIMER0B 5
#define TIMER1A 9
#define TIMER1B 10
#define TIMER2A 11
#define TIMER2B 3

void PWM(uint8_t pin, uint8_t val){
	/**
	 * If PWM is in fast mode val == 0 does not work
	 * if (val == 0) {
	 *   PORT &= ~_BV(PIN);
	 * } else {
	 */
	
	if (pin == TIMER1A) {
		TCCR1A |= _BV(COM1A1);
		// set PWM duty
		OCR1A = val;
	} else if (pin == TIMER1B) {
		TCCR1A |= _BV(COM1B1);
		// set PWM duty
		OCR1B = val;
	} else if (pin == TIMER0A) {
		TCCR0A |= _BV(COM0A1);
		// set PWM duty
		OCR0A = val;
	} else if (pin == TIMER0B) {
		TCCR0A |= _BV(COM0B1);
		// set PWM duty
		OCR0B = val;
	} else if (pin == TIMER2A) {
		TCCR2A |= _BV(COM2A1);
		// set PWM duty
		OCR2A = val;	
	} else if (pin == TIMER2B) {
		TCCR2A |= _BV(COM2B1);
		// set PWM duty
		OCR2B = val;
	} else {
		extern void error(uint8_t errorCode);
		error(12);
	}
}

Ian.M · « **Reply #42 on:** September 25, 2018, 06:54:46 pm »

Another option would be to eliminate the TLC5940 and instead use smart RGB LEDs, e.g. WS2812 (aka: Adafruit Neopixels) or APA102 (aka: Adafruit Dotstar). There's an Arduino Neopixel library that handles the tightly timed WS2812 single wire interface, or if you use APA102 based LEDs, its a two wire SPI interface with no timing constraints, and yes, there is an Arduino library for it.

Neopixels don't play well with background interrupts, but for a limited string of them, it would be possible to wait for a safe time in the servo frame to call pixels.show() to update them without causing servo jitter.

Youkai · « **Reply #43 on:** September 25, 2018, 11:42:23 pm »

This one would probably work perfectly for my needs: https://www.adafruit.com/product/1426

So if I were to do this I would use 5 total PWM pins? 1 each for the 2 LED strips and 1 each for the 3 servos? Actually this https://learn.adafruit.com/adafruit-neopixel-uberguide/basic-connections says "any digital pin" can be the data pin so I wouldn't even need to use a PWM pin necessarily it seems. Yeah I'm just gonna do this. It will make the wiring much easier. Oh also this NeoPixel Stick needs a 5v power supply so I can take the transistors out too! happy days.

I'm not sure I understand the comment about background interrupts. Do you mean like if I were to use attachInterrupt() from the Arduino library? I wasn't planning on using that in my code so I think this won't be an issue.

EDIT: Ordered the RGBW one instead since I'm going to use one to light the inside when open so having a true white option would be good. https://www.adafruit.com/product/2869

Ian.M · « **Reply #44 on:** September 26, 2018, 03:21:55 am »

The problem is the servo library uses interrupts, and if one occurs during pixels.show(), that would corrupt the data transfer to the LEDs. Therefore the show() method disables interrupts while it is outputting the pixel data. This will make any servo jitter if its servo pulse edge is due to occur while show() is executing. To avoid that, before calling show(), you need to poll the timer controlling the servos to check if its past the end of the last servo pulse and is waiting for the end of the 20ms servo refresh frame.

Youkai · « **Reply #45 on:** September 26, 2018, 04:15:44 am »

Ok that is way over my head. Do you have any links to examples that do that? Or keywords i can search to learn how?

Also correct me if I'm wrong but communication with the servo only happens when I issue a command to change position right? And once that command is complete there is no more communication with the servo. So as long as i don't try to change the LED color for a short time after moving the servos there shouldn't be an issue. Is that correct?

Ian.M · « **Reply #46 on:** September 26, 2018, 05:20:17 am »

Once you activate a servo on a pin with servo.attach(pin), the servo ISR continues pulsing that pin even when you aren't moving the servo. If you stop it, one of four things may happen, depending on the servo - it may stay where it is, or power down, or drive to a preset 'safe' position, or drive to either limit. Unless you know what the servo is specified to do on loss of signal, and that's power down or hold position, it isn't safe to use servo.detach().

Most Arduinos will use Timer 1 for the servo library (see ServoTimers.h in the library for exceptions).

In Servo.cpp:

Code: [Select]

#define usToTicks(_us)    (( clockCyclesPerMicrosecond()* _us) / 8)     // converts microseconds to tick (assumes prescale of 8)  // 12 Aug 2009

defines the relationship between timer ticks and us.
In Servo.h:

Code: [Select]

#define MIN_PULSE_WIDTH       544     // the shortest pulse sent to a servo  
#define MAX_PULSE_WIDTH      2400     // the longest pulse sent to a servo 
#define DEFAULT_PULSE_WIDTH  1500     // default pulse width when servo is attached
#define REFRESH_INTERVAL    20000     // minumim time to refresh servos in microseconds

gives the limits for one servo pulse, and the total frame length.

The servo library outputs pulses to its active channels consecutively during the servo frame. Therefore if you are controlling three servos, there's a gap between approx 7.2ms and 20ms in the servo frame where you can be certain no servo pulses are being output. That's when you need to update the neopixel string(s).

As usToTicks() is private in the Servo lib, you need a copy of its definition in your sketch, then you can simply do

Code: [Select]

while(TCNT1<=usToTicks(8192)){};
pixels.show();

which waits for the gap in the servo frame before updating the neopixels. For 16 RGBW neopixels, show() has 512 bits of data to send, which will take approx 0.7us @800KHz pixel clock.

N.B. you can daisy-chain the neopixel strips by connecting DIN to DOUT, so you'll only need one I/O and one call to the show() method for all the neopixels.

Youkai · « **Reply #47 on:** September 26, 2018, 08:19:51 am »

I see. Thanks for the great info Ian.M. I'll do some testing with that in the near future. I know I can chain the LED together but I wasn't planning on it because they are kind of in opposite directions from where the micro-controller will be. I guess it wouldn't be too far out of the way to chain them. Is one call to show() less than half the time of two calls? I'm only calling it once but I'm sending twice the data correct?

Also my schematic is MUCH simpler now. The new LED run on 5V so that takes out the transistors and the buck converter. Here is the new schematic. Wire colors don't mean anything other than Yellow=Positive and Black=Negative. I think it still needs a little work. According to the notes on the Adafruit site I need to have a capacitor in there for the LED's. Need to do a little more research.

Ian.M · « **Reply #48 on:** September 26, 2018, 10:22:08 am »

There's a small overhead in show() for setting up the transfer and the reset gap that latches in the data, so one show() would be ever so slightly faster, but if its physically inconvenience to daisychain them, there's no reason not to put them on separate pins then:

Code: [Select]

while(TCNT1<=usToTicks(8192)){}; // Wait till no servo pulses
pixels1.show();
pixels2.show();

You definitely need a *lot* of bulk decoupling capacitance for the Neopixels and the servos. Unfortunately the USB standard calls for a maximum of 10uF on Vbus in a device, which is far too low for running servos on the same 5V rail as a MCU, and if you exceed the 10uF permitted by the standard significantly, you'll have problems with USB over-current at plug-in, or erosion of the connector contacts due to sparking. It would therefore be preferable to keep the buck converter and power it all from a higher voltage. The Arduino would use its onboard regulator and the servos and Neopixels would be fed by the buck converter. The seperate servo/neopixel +5V and Arduino +5v prevents servo noise crashing the Arduino. Also, it could be programmed via USB with just the Arduino powered, and there'd no USB excessive inrush current problem. You'd use an I/O pin to detect if the buck converter is outputting 5V so that the code would only enable the Neopixels and servos if they are powered.

N.B. Adafruit recommend a 470R resistor in series with DIN between the Arduino and the Neopixels to prevent damage to DIN due to transients on the data line. If you don't want dead Neopiexls fit the resistors! Also, similar resistors in the servo control lines would be advisable.

Youkai · « **Reply #49 on:** September 26, 2018, 03:33:34 pm »

Ok cool beans. I'll update my schema to include the buck again and add the other stuff.

I'll obviously power the Pro Micro from USB while programming it but it's going to be powered by the buck converter in live use. That shouldn't be a problem right? The "RAW" input on the Pro Micro has some kind of regulation on it I believe.

Do I just put one capacitor across the two output lines of the Buck converter; before any connections to any powered device?


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Borderlands style jewelry box research thread (Read 12048 times)

Share me