Quantcast
Channel: Wardy's Projects
Viewing all 70 articles
Browse latest View live

DS1077 + Arduino

$
0
0
I've finally had a chance to get around to playing with the DS1077 configurable oscillator!

The circuit to get it working is very simple, just hook up the Ardiono as the I2C master, I used a 10K pullup resistor on both the SCL and SDA lines.  I tied CTR0 and CTR1 on the DS1077 to GND to enable the chip all the time.  For the following video, I put the scope probe onto the OUT1 pin...



You'll see some substantial "ringing" on that scope trace in the video.  Ignore that :) it's because I'm sending fast rising and falling edges through a cheap breadboard, cheap hook-up wires, and a very cheap croc-clip oscilloscope probe.  This chip produces rather good quality square waves signals when under ideal circumstances.  This video simple demonstrates the nice smooth way that the frequency can be varied by sending I2C commands to the chip.


Here's a quick schematic for that hastily breadboarded demo circuit...

I like the pinout of this chip, as it clearly demonstrates deference to signal integrity design considerations for the PCB designer.  Notice how the VCC and GND pins are side by side.  That makes it very convenient to place a decoupling cap right on those lines as close to the chip as possible.


And of course here's the obligatory Arduino source code to drive the chip.  This is the code used for the video.  All it does is run through the entire frequency range supported by this chip.  Hopefully this will be of some help to fellow blogger Eldon (http://wa0uwh.blogspot.com/)who showed some interest in this chip from my previous post on the topic.


#include 

const int ds_address = 0xB0 >> 1; //DS1077 default address

#define MUX_HI_PDN1_BIT (B01000000)
#define MUX_HI_PDN0_BIT (B00100000)
#define MUX_HI_SEL0_BIT (B00010000)
#define MUX_HI_EN0_BIT (B00001000)
#define MUX_HI_0M1_BIT (B00000100)
#define MUX_HI_0M0_BIT (B00000010)
#define MUX_HI_1M1_BIT (B00000001)

#define MUX_LO_1M0_BIT (B10000000)
#define MUX_LO_DIV1_BIT (B01000000)

#define BIT_ON (0xff)
#define BIT_OFF (0x00)


void setup()
{
Wire.begin();
}

void loop()
{
long i;
for(i = 0 ; i <= 1025 ; i+=1)
{
i2c_write(ds_address, 0x02,
( 0
| (MUX_HI_PDN1_BIT & BIT_OFF)
| (MUX_HI_PDN0_BIT & BIT_OFF)
| (MUX_HI_SEL0_BIT & BIT_ON)
| (MUX_HI_EN0_BIT & BIT_ON)
| (MUX_HI_0M1_BIT & BIT_ON)
| (MUX_HI_0M0_BIT & BIT_ON)
| (MUX_HI_1M1_BIT & BIT_ON)
)
,
( 0
| (MUX_LO_1M0_BIT & BIT_ON)
| (MUX_LO_DIV1_BIT & BIT_OFF)
)
); //mux
delayMicroseconds(100);

i2c_write(ds_address, 0x01, (i >> 2), (i << 6) & 0xC0); //div
delayMicroseconds(100);
i2c_write(ds_address, 0x3F);

delayMicroseconds(10000 - i);
}
}

void i2c_write(int device, byte address) {
Wire.beginTransmission(device); //start transmission to device
Wire.write(address); // send register address
Wire.endTransmission(); //end transmission
}

void i2c_write(int device, byte address, byte val1) {
Wire.beginTransmission(device); //start transmission to device
Wire.write(address); // send register address
Wire.write(val1); // send value to write
Wire.endTransmission(); //end transmission
}

void i2c_write(int device, byte address, byte val1, byte val2) {
Wire.beginTransmission(device); //start transmission to device
Wire.write(address); // send register address
Wire.write(val1); // send value to write
Wire.write(val2); // send value to write
Wire.endTransmission(); //end transmission
}


This chip lets you output a 50% duty cycle square wave at any frequency given by 133,000,000 divided by any number between 1 and 1025 inclusive.  This divider is selected by sending a short I2C sequence to the chip from whatever microcontroller you prefer.  I'm using an Arduino here because there was some code easily available for it.  For my final purposes I'll be using a P8X32A Propeller to drive this chip.

This is a fun chip to mess with and has some substantial benefits for the advanced Parallax Propeller user, since this will let you experiment with letting the Propeller chip overclock itself on the fly!  Granular clock management and tuning is something I'm interested in experimenting in with the Prop and this chip will be a great way to do it!

I think this chip will also be of use to Ham radio enthusiasts because of it's frequency modulation abilities.  Although I suspect that it's stepped frequency brackets are a bit of a limitation for some of the really advanced shenanigans of the Ham community, this would be useful for some kind of carrier modulation or FDM projects.

Anyway, sorry for the long-winded post - hope you find this useful or at least interesting.

Wardy.

RasPi R2 Pinout

Prototype Propeller Accessory for RasPi

$
0
0
The prototype for my Propeller accessory is pretty much finished now.  The final one will be a proper PCB with hopefully FOUR Propeller chips on it!  I'm using one for this prototype to ensure that the basics are working such as I2C and bidirectional serial comms between the Pi and the Prop.


The Prop Plug is only temporary and allows me to get an extra debug channel into the top board while debugging code running on the Pi.

This board has 24 GPI pins available to the user.  The final build might have as many as 64!

Next I'll be adding the code that lets me talk to the Prop over the Pi's GPIO pins using Serial.  I'll need to find way to drive an extra pin to bring the Prop out of reset at the right time during comms.

Then, after that I'll be hooking up the DS1077 chip (with 3v3 / 5v level shifters) and making the Propeller dynamically change it's clock speed!


Success - RasPi programs a Propeller!

$
0
0
I've managed to get my RasPi module to program a Propeller and it's EEPROM using my "pushprop" program compiled and running on the RasPi under Raspbian.

This was an interesting part of the project, as there were some obstacles due to the nature of the RasPi's architecture.  pushprop can actually program the Propeller over either the 0.1" pin header connection to the accessory board I'm building - or - it can program it over the normal USB/FTDI (e.g. "PropPlug") connection.

Since the RasPi hasn't got a dedicated DTR pin on it's GPIO header block, I had to commandeer GPIO_0 and wire it directly to the RESn pin on the Propeller (there's also a pullup resistor on that line to allow the Propeller to operate even when the RasPi isn't connected).

Now I can program the Propeller chip without using any cables, the next step is to hook up the DS1077.

Musings on dynamic clocking of microcontrollers

$
0
0
Before I embark on a voluminous treatise on the nuances of on-the-fly clock signal modulation I had better think about the potential pitfalls that might arise.

Assuming that a DS1077 Programmable Oscillator is hooked up to a Propeller P8X32A microcontroller so as to have the Propeller take it's external clock directly from the DS1077, is it possible to write code in such a way that the system becomes bricked?

Yes, in certain circumstances.  The DS1077 has two enable pins which, if configured correctly, can shut off the outgoing clock pulses from both OUT0 and OUT1 pins.  If this happens while the microcontroller is still using the DS1077 as it's clock source, the program will halt completely.  In the case of the Propeller, all 8 cogs and the Hub will all cease activity altogether and will therefore be unable to communicate with the rest of the system.  The only way to get out of this is to put some simple safeguards in there...

Safeguard 1:  Have the Propeller perform it's initialisation code using it's own internal silicon clock.  This will ensure that the DS1077 chip will always be contactable after a reset or a power-cycle.

Safeguard 2: Force the DS1077 to be running all the time.  This can be done by choosing sensible configuration settings and then tying the two enable pins (CTRL0 and CTRL1) directly to GND.

Safeguard 3: When using I2C to reconfigure the DS1077, always make your microcontroller change over to it's internal oscillator BEFORE starting the I2C sequence.  Then allow a sensible amount of time (a couple of microseconds is probably enough) to elapse before switching back to using the external clock source again.  This guarantees that your communications with the DS1077 are always glitch-free and reliable.

Something to remember: changing the clock speed of your circuit programmatically requires your microcontroller firmware to be a bit more sophisticated with it's handling of things like fixed duration waits or delays.  Waiting 1,000,000 clock cycles at 16KHz will take more than one minute to elapse, whereas waiting 1,000,000 clock cycles at 133MHz will take 7.5 milliseconds!  Consequently it is vitally important to remember what clock speed you're running at at any given moment.  Again, a fail-safe method of being absolutely sure that you have a known clock rate is to fall back on using your microcontroller's internal oscillator.


Rule 2: follow all the rules.

$
0
0
For once I followed the First Rule of Electronics Troubleshooting (FRET):

  1. Check your voltages.
(from Leonardo da Vinci - "Reprehendo Tuum Voltages", quote from unpublished notes, volume 19 chapter 11)


While trying to integrate the DS1077 programmable oscillator into my RasPi/Propeller prototype accessory, I noticed that I was getting a very glitchy IO signal on an LED I was using for debugging.  I was using the LED to signal when an event had happened in the I2C comms process.  This showed up when I attached my logic analyser to the IO pin connected to the LED.  There was an intermittent fault on that line that could not be a result of the PASM code running on the Propeller.

Hmm.  What to do?  What do we know about the circuit?  We know that the RasPi behaves itself very well when the prototype board isn't attached, and when it is attached, the RasPi continues to function correctly.  This means the problem is internal to the prototype board and seems not to cause the RasPi any problems.

That doesn't exonerate the RasPi of blame though.  Nosiree.  A poke with a multimeter tells me that the "5V" rail on the RasPi is sitting at a very stable but somewhat sickly 4.72 volts.

Next I checked the Propeller's supply voltage - which is the output of the LD33V LDO voltage regulator.  This was found to be a nonchalant and debonnaire 3.3 volts - perfect.

Onwards to the DS1077 which runs directly from the "5V" rail on the RasPi.  I have to confess ignorance here.  I foolishly neglected to verify the quality of the "5V" rail on the RasPi board.  Turns out that the "5V" rail is simply hard-wired to the power input which in my case comes directly from a Kindle charger wall-wart.

The DS1077 datasheet states that the acceptable range of VCC is between 4.75 and 5.25.  I think that's the culprit right there.  I'm running that DS1077 chip from a weak VCC source which is barely grazing the acceptable range.

Interesting.  So hopefully if I can provide a stiffer 5V supply for the RasPi (by using a wall wart with a greater current range), I can do away with these glitches in other parts of the system.  This also indicates that I can't easily run 5V devices off the 5V rail of the RasPi necessarily.

For the final design I'll need to use some additional circuitry to filter noise on the 5V rail into the prototype board!  Ferrites and caps will help in that regard.

We live and learm :).

RasPi Propeller Shield - work commences!

$
0
0
Like any other electro-mechanical-engineeringly inclined hobbyist, I've spent my fair share of time drooling over the promotional videos for products like Solidworks or Zuken CR8000, but I'm still always excited by what can be accomplished with cheap and mainstream tools like DipTrace and Sketchup.

Today I started to put together the first stages of the design I am planning to use for my Raspberry Pi shield.

There's no electrical schematic yet, but I've chosen some of the important components and with about 4 hours of dithering about with dimensions and feature snapping and such, a fair amount of the groundwork was done...





SketchUp was first used to create a 3D model of the RasPi with accurate dimensions (I hope!).  Then this was used as a template from which a basic PCB outline for the shield was generated, again with dimensions that should correspond to the RasPi anatomy.

Then it was over to DipTrace to start preliminary work on the Schematic and Layout designs.  The second picture here shows the Layout with the four Propeller QFP chips (P8X32A-Q44) laid out in a vaguely sensible location on the shield.  In the middle is the DS1077 programmable oscillator which (if all plans go well) will provide a solid clock signal for all four Propeller chips to operate from.  I've not yet decided on how I' going to organise EEPROMs on this board yet.  I'll probably provide two 64KB eeproms shared between the four Propellers.  As for extra RAM, I'll am thinking about using some fast SPI SRAM chips (one per Propeller) to supplement the on-silicon RAM in each chip.

There's a huge amount of work to be done before I get any prototypes made but that's all part of the fun.

But this is all fairly trivial to do even with modest tools within reach of the serious hobbyist.  But that's not to say I won't still be pining for a copy of Solidworks to drop through my letterbox one day :)








Propeller network layout for RasPi accessory

$
0
0
Four Propellers... 64 user-GPIO pins... 1MB distributed SQI SRAM... Dynamic clock modulation...

... makes for a lot of head-scratching and frowning.

I've been roughing out a design for a PCB that has all of the above features.  Nothing particularly complex in it's intrinsic form but may lead to some quite interesting possibilities for those interested in high-speed signalling or even RF modulation (HAM radio).

Here's a simplified sketch of the Propeller network...

Here we have "M" (master) which talks directly to the RasPi and coordinates the three slave Propellers.  M controls the startup sequence for S0, S1 and S2 and also acts as a system watchdog, able to reset each slave if required.

All 4 Propellers have 16 GPIO pins exposed via male 0.1" headers, up to 256KB of SQI SRAM, and I2C access to the 256KB EEPROM.

Not many pins left now, 2 remaining unused on each slave, and the Master has none left.  Although I'm thinking of dropping the Master's GPIO exports down to 8 instead of 16 and gaining 8 more specific purpose pins for implementing some more cool features.

In any case I'm trying to make this a powerful board that concentrates on a good range of fast resources and the ability to generate high speed signalling on many pins simultaneously.  But each Propeller has a direct asynchronous connection to each other Propeller, so it will be possible to constuct some very complex systems with both high speed processing and high-resolution, low latency IPC channels.


BeagleBone Black - EEPROM

$
0
0
Last week I took delivery of the new Beaglebone Black (see HERE and HERE).  If you like the RasPi you'll love this too, only more so.

Since I'm a pathological accessory maker for such devices, I have started prototyping a new "Cape" (as the BBB fraternity call them, the rest of the world would probably think of the word "shield").

Starting from the basics, I simply grabbed a bit of perfboard and soldered some header pins to it so I can connect it to the P9 socket on the BBB.  Unlike the arduino or raspi, the BBB specification gives some guidelines about how you should design your cape.  For starters you need to put an EEPROM chip on there from which the BBB will read configuration information at bootup time.  This config tells the BBB what pins are in use by the cape and what the cape is called and who manufactured it among other things.

I had a Microchip 24LC256 handy so I tried that and it worked just fine after a few false starts (which I quickly rectified by RTFM!).  That's one thing you have to do... READ the manual first... all of it...every single page.  I'm not kidding.  It'll save head-scratching later.  It's only 100 pages so it's a lunch-hour's read.  IMHO it's overly wordy and doesn't get to the point fast enough, a bit too waffly for my liking, but hey.

My cape currently has nothing on it but the EEPROM which is set to address 0x54 (A0, A1, A2 = low, low, high).  I verified that the EEPROM was visible to the BBB by running these commands...




root@beaglebone:~/code/anw_cape# echo "fish" > /sys/bus/i2c/devices/1-0054/eeprom
root@beaglebone:~/code/anw_cape# cat /sys/bus/i2c/devices/1-0054/eeprom | xxd | head -n 3
0000000: 6669 7368 0aff ffff ffff ffff ffff ffff  fish............
0000010: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000020: ffff ffff ffff ffff ffff ffff ffff ffff  ................


Removing the cape and repeating this fails with device timeouts, replacing it again and it succeeds.

Great!  So the next step is to generate a well-formatted EEPROM content file that the BBB can understand and use to configure itself and then interact with the cape when it gets more features later on.

Back to the manual for a bit more reading...

BeagleBone Black - EEPROM (2)

$
0
0
Carefully crafting the contents of the 32KB EEPROM image, and then writing it into the appropriate device handle followed by a reboot yields this result...


Despite the horribly slow EEPROM write cycle, this procedure is really quite painless. The prototype "cape" as it currently stands is literally just a bog-standard Microchip 24LC256 EEPROM attached to pins 19 and 20 on the BBB. That is not even the EEPROM that is suggested in the BBB's SRM. I guess one generic 32KB I2C EEPROM device is as good as any other (as my Great-Grandfather used to say).

Beaglebone Black - EEPROM (3)

$
0
0
Descending further into the dimly-lit (figuratively and literally, since the documentation for this stuff is so hard to find) recesses of the BBB architecture, another minor success registered today.

I was able to put together a Device Tree Binary (.dtbo) file that the Angstrom OS can associate with my shield's EEPROM image.  This basically means that if you attach the cape and then boot up the BBB, the BBB will absorb the .dtbo file into the overall system-wide device tree!

[ 3.605835] bone-capemgr bone_capemgr.9: slot #0: dtbo 'WPBBB-Experiment-00A0.dtbo' loaded; converting to live tree
[ 3.606012] bone-capemgr bone_capemgr.9: slot #0: #2 overlays
[ 3.606744] bone-capemgr bone_capemgr.9: slot #0: Applied #2 overlays.
[ 3.606763] bone-capemgr bone_capemgr.9: loader: done slot-0 WPBBB-Experiment:00A0 (prio 0)

The format of the ".dts" file (a human-readable source code before it is compiled into a .dtbo binary) is somewhat complex and frankly intimidating, so I'll have to study it carefully if I want to make good use of it.

So anyway, my BBB now recognises my cape and at least has the beginnings of being able to configure itself to match the requirements of the cape's IO needs.  There is much work still to do though, I must write code for the ATMega I'm planning to add to the cape, and also the custom BBB device driver to allow the BBB to talk to the cape and pass data back and forth.

Fun :)



Sometimes luck beats perseverance

$
0
0
Had one of those warm fuzzy moments where you're on the verge of throwing a piece of hardware in the dumpster when somehow you stumble over the tiny nugget of information that has been evading you ever since the problem arose.

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1069102#1069102

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=82994

keywords so I can find this again... :
avrisp mkii, windows 7, driver, problem, fix, success, avr, atmel, atmega, avrstudio, computer management, legacy driver

Controlling six 17-segment digits using three I/O pins

$
0
0
Decided to start making good use of my "Propeller Professional Development Board" (PPDB) which has been sitting sadly idle and forlorn on the bench for a while.

Set a goal of making a simple video game with some of the advanced features available on the Propeller and this great dev board.

The first thing I wanted to get working was the bank of six 17-segment LED digits.  It would be neat to have the player's score show up in the LEDs  as well as any "Insert Coin" or "Game Over" messages.

Due to the Propeller P8X32A chip's eight CPU cores (each running at 20MIPS) I figured upon the following distribution of work between the cores...

Cog 0: low-speed tasks such as user input, LED display, and system watchdog.
Cog 1: VGA video (resolution to be decided, maybe 800x600).
Cog 2: Game logic (snake, tetris, crysis 3).
Cog 3,4,5: Video scheduling
Cog 6: Audio output
Cog 7: Something similar to (but legally distinct from) "ambilight" functionality.

Today I wrote some simple PASM code that displays some arbitrary text on the 6 digits of the PPDB.  I used a cascaded chain of three 74HC595 chift register chips to provide signalling to the 595s.  Conveniently, the 595's have a neat feature that lets you control this entire multiplexing challenge using only three (count 'em) output pins from the Propeller chip.  I used one output to control the "nG" (enable output) line, another pin to provide the "SI" (serial input) to the shift registers and a third output pin to clock RCK and SCK simultaneously.

Three output pins to drive 102 LEDs at high speed.  And it looked fantastic too.  A little too fantastic really.  The Propeller chip is so fast that it can easily generate smooth light patterns on the 6-digit display.  I'm going for a retro feel to this game so I felt that it would be cool to make the 6-digit display flicker in some jittery manner that might give the impression of old VFD displays.  The smooth pattern seems to be a bit lacking in the "retro" feel I'm looking for.

I contrived to add this retro effect by deliberately introducing some pseudo-random interruptions to the 6-digit display code.  By using the Propeller's 32-bit clock counter register, shifted, truncated and masked (all arbitrarily) and mixed with the code that decides which LED is lit at the next cycle, it was possible to generate a pattern that causes a nice pulsating effect that gives the impression of a cheap, underpowered display driver on a cheap game system.

Unfortunately, I couldn't capture this pulsing, strobing effect on my crummy Samsung camera because the Propeller's output frame rates are too high to register on the camera's preview.

It does look pretty cool to the naked eye though.

Here's a still of the cool blue LEDs...
http://farm4.staticflickr.com/3810/8989256270_2687b17b62_o_d.jpg

CODE: https://dl.dropboxusercontent.com/u/24469109/randomblogcrap/ppdb17segmentspasm/17-segments.spin

Craply rendered schematic: https://dl.dropboxusercontent.com/u/24469109/randomblogcrap/ppdb17segmentspasm/schematic_17-seg.png















Black Sabbath - "13"

Celestial Camera Mount

$
0
0
A couple of years back, while on holiday I took a few photos of the night sky with my DSLR camera and the standard lenses.  Doing this gives some appreciation of how the solar system moves in relation to our galaxy (the Milky Way).  The most noticable effect is the streaking of the stars due to the rotation of the Earth.  Since the camera and tripod are standing on the ground - they are fixed in relation to the earth and thus the camera's field of view will sweep very slowly across the sky.

Here's the clearest shot I managed to take on that trip:

You can see if you look closely that each star is elongated because of the combination of a 5 minute exposure and the distance that the Earth rotates in those 5 minutes.

I wanted to try to get a streak-free photo during this year's holiday (assuming the clouds stay at bay!).  So I need to find a way to cancel out this phenomena.  There are at least two options: 1) stop the Earth's rotation, or 2) rotate the camera in the opposite direction to compensate.

Option 1 presents some practical difficulties and is likely to have some environmental complications attached to it.
Option 2 seems ideal though.

Using a microcontroller (ATMEGA328P) and a stepper motor (plus driver board) I plan to build a motorised panning attachment for my tripod that will slowly rotate the camera in the opposite direction to the Earth's rotation and at the same speed as the Earth rotates.

How long is a day?  Turns out that in this context (making the stars stand still from an Earth viewpoint) a day is not quite 24 hours long.  We're used to our Earth day being governed by the illumination of the sun Sol.
When the Earth does a 360 degree revolution in relation to the stars, it has not yet done a full 360 degree revolution in relation to the sun because the Earth has move around its orbit by one 365th of a full orbit (approx).  According to Wikipedia (http://en.wikipedia.org/wiki/Rotation_period or http://en.wikipedia.org/wiki/Day) the stellar Earth day is about 4 minutes shorter than the Solar day.

If you want to prove this yourself - pick a bright star and line something up with it accurately.  Then come back *exactly* 24 hours later and see if it's still aligned.  The star will be a tiny bit shifted off to one side (depending on which hemisphere you live in).

In the northern hemisphere an observer facing south will see the stars above moving from left to right as the Earth turns.  My device will need to drive the camera from left to right in order to remain fixated on the same point in the night sky.

I plan to use the stepper motor to drive a reduction gearbox (something like 500:1) to drive the axle on which the camera will be mounted.  So there are come calculations to do.

1 stellar day is 86164.098903691 seconds long on average.
So the Camera needs to do 1 full 360 degree turn in that time.  The stepper motor I'm using has a 200 steps per revolution which equates to 1.8 degrees per step.  However the driver I'll be using (Schmalzhaus EasyDriver v4.4) has the ability to microstep at 8 times better resolution than that, so effectively it's 1600 steps per revolution on the stepper shaft.
I have still to ascertain the actual ratio for my gearbox (it is not stated explicitly on the product).  I'll have to open it up and count the teeth on the gear sequences.  Once that is known I'll multiply this ratio by 1600 to get the number of ticks required to make the camera swing through a full 360 degrees.  If this is a 500:1 ratio then it'll be 800,000 steps per camera revolution!!!  That will be more than enough resolution for really nice smooth camera motion.  A large ratio like that also helps reduce the strain on the stepper motor if a heavy camera or a long lens is used.

Ultimately I need to have the ATMEGA328P fire a step pulse every (86164.098903691 / 800000) == 0.107705 seconds.  If I use a decent 1MHz oscillator as the microcontroller's clock source I can send a step pulse every 107705 clock cycles.

This design should be pretty easy from an electronics perspective, but it will require some metalworking to fabricate some aluminium parts to form the axle supports and camera attachment brackets.

I hope to do a full build log with parts list and schematics and mechanical drawings once I've finished it.



Celestial Camera Mount (Pt 2)

$
0
0

Just finished the hardware part of the control board for the camera mount.  I'm using a 7.2v NiCAD RC car battery to power the whole thing.  Conveniently, the EasyDriver board I'm using (the red board mounted on headers to the microcontroller board) has a 5V output that can be used to power the microcontroller, so that saves my throwing down a regulator and a bunch of caps.  For sanity's sake I put a rectifier diode between the 5V output and the microcontroller's VCC pin to ensure that nothing is driven the wrong way when i'm using the ISP header to program the microcontroller.

The code and hardware work well but the driver chip on the EasyDriver gets very hot very quickly, so it'll definitely need a heat sink on there when running it for long periods.  I might even mill out an aluminium case in such a way that the case itself forms a heatsink which should work well in the cool nighttime air.

Next job is to figure out what the input:output turns ratio is for this gearbox.  And also design the mounting plate that will let me attach the stepper to the gearbox.

Annoyingly, the worm screw that I epoxied to the stepper shaft didn't set straight, despite my best efforts to align it.  There's about 0.25mm of deflection at the worst position in the stepper's travel.  I will probably have to break it off and try again, unless I can make a somewhat flexible mounting plate that will allow for this.  A combination of aluminium and rubber would probably make this possible.

Anyway, the build is on target now I've got the tricky bit (the electronics) out of the way.


Idea for concentrically aligning a worm screw with a motor shaft

$
0
0

Having failed to correctly align this screw section with the end of this stepper motor shaft in a previous blog post, I thought some more about a better way to do it.

Then it hit me - I could use a drill press (or a milling machine) to do it.

1. UNPLUG the drill!  No, seriously, really unplug it. Do it.
2. Open up the chuck and insert the motor shaft in there and gently tighten it.  If you use a milling machine, lock the table in position with the locking screws.
3. Lower the spindle until the body of the motor is resting flat on the drill press table surface.
4. Secure the motor body to the table using gaffer tape or blu-tac or whatever you like, just to keep it motionless while you undo the chuck.
5. Open the chuck completely and raise the spindle again, leaving the motor fixed to the table surface.  At this point the motor shaft is still concentric with the spindle.
6. Insert the worm screw section into the drill chuck and gently tighten.  Do not damage the screw's thread.
7. Put a tiny amount of epoxy (I used two-part araldite) onto the end of the motor shaft.  Don't get adhesive inside the stepper motor else you'll have a very unusual paperweight.
8. Move the spindle down until the screw just touches the end of the motor shaft.  Do not press down on it.
9. Lock the spindle in place.
10.  Walk away and wait for your epoxy to go off completely.  I waited a whole 24 hours, because this wan't a time-sensitive part of the build.

11. when you're satisfied that the adhesive is set, carefully open the chuck and raise the spindle.  Then liberate the motor from the table.

That's it! It does have the disadvantage of tying up the machine for a while but I can live with that given that this method would give very accurate alignment.

I've been watching a lot of metalworking videos on youtube lately and this idea came to me just now.  It's amazing how versatile simple metalshop tools can turn out to be.

Gearbox Calcs

$
0
0
SAM_1485

I would invite any mathematics enthusiasts among you to attempt to calculate the input : output ratio of this gearbox.  With the help of a learned colleague at work I was able to settle on 931.222222 worm revolutions per output shaft revolution.

I am not sure I have calculated this correctly as it seems a little on the high side to me.

My calculation was thus:
1/((1/25)*(10/34)*(9/29)*(10/34)) = 931.2222...

Does that sound right?  Time will tell.  I am currently awaiting the arrival of some new tools that will enable me to progress with the metalworking aspects of this build and finally affix the stepper motor to the gearbox via a worm screw.  Then it will be but a trivial matter to have the stepper motor move a full (931.222222 * 200 = 186244.444444 (full) steps and see if the output shaft does precisely one revolution.  If not then I'll have to recalculate!

I obtained this gearbox for about £13 on Ebay, having bought it with the expectation that it would be a cheap piece of flimsy crap that would fall apart after a bit of machining.  Turns out it's actually pretty decently made (for it's price) and has metal gears within, which is a bonus.  I didn't know what the ratio would be before hand, only that it was fitted with a 12VDC reversible motor and had a rated output shaft speed of 8RPM.

My limited knowledge of 12VDC motors told me that they probably spin at a few thousand RPM at the motor shaft, 8RPM on the output must mean it's got a pretty awesome gear reduction.  Such a reduction gives me lots of torque to play with and also a very fine resolution on the positional accuracy of the output shaft.  This is increased even more because my stepper motor driver can microstep down to 1/8th of a regular step.  1600 steps per revolution on the input shaft to a gearbox with a 931.2222:1 reduction gives me a mind-meltingly fine resolution of 1 part per 1489955.6.

That is to say, my stepper motor needs to microstep 1489955.6 times per day in order for my celestial camera mount to follow the starfield movement perfectly.  That's one microstep every.... (86164.098903691 / 1489955.6) = 0.05782998 seconds.  Or one about microstep every 57830 clock cycles when running from a 1MHz crystal.

17.3 micro steps per second or so.  Sounds reasonable.














Stepper driver heatsink assembly

$
0
0
Some random pics of the ludicrously excessive heat sink I'm using to keep the EasyDriver's main IC cool can be seen below...


Eagle-eyed readers will notice that the heat sink is from the graphics card of a 1st generation XBox360 (one that perished among countless thousands of its brethren in the Red Ring of Death catastrophe.  It served me well in life, now may it do so in death.

To be honest, this is complete overkill but it does also provide a nice surface I can screw other things to in order to affix everything to my camera tripod.

Heat sinking of some sort is definitely required though, that chip you can see pressed hard against the heat sink does get very hot indeed.  Hot enough to elicit blasphemous utterances from those incautious enough to let a stray finger brush past its surface when the heat sink is not attached.  With the sink on there, the temperature of that IC package merely hovers around the 45 celcius mark while on my workbench.  Given that this unit will be deployed in the cool air of the witching hour outside in autumnal months, heat is no longer a problem. :) 

Random drawing of the week

$
0
0
Mounting plate for the celestial camera mount.  Stepper attaches from one side, gearbox from the other.




Viewing all 70 articles
Browse latest View live