Saturday, December 31, 2011

Creating PCBs addendum - drilling

Just a quick one to finish up the Creating PCBs series. I've loaded the demo PCB into the CNC machine and set it up to drill the header holes.
Here's the final result:
The area on the right is where I attempted to tin some tracks with solder. I need some new solder wick I think, and some liquid flux.

Some stats on how the drilling was done:
1mm HSS drill bit in a standard mains power drill, mounted in my homemade CNC machine. The power drill nameplate says 2700 rpm max speed. I had it set to max, so the "spindle speed" was somewhere near that.
CNC driven by EMC2 from a IBM Thinkpad G40
G-code generated by pcb-gcode user-language program in Eagle 5.11
Feed speed: 90mm/min.
Drill depth: 2mm
Retract height: 1mm
Dwell: 0.1 seconds

I had to add these commands to the generated gcode output to get it to work correctly:
F90 (set feed rate 90mm/min)
Z-2 R1 P0.1 (set Z depth, retract and dwell, added to first drill line only. Values still apply on subsequent drill movements)

And of course, here's a video of the CNC in action...




Tuesday, November 15, 2011

Creating PCBs - Etching and Lessons Learnt

Next step, after exposing the photo-resist and developing the un-exposed areas away is to etch away the copper where is has been exposed.
This was done in a solution of ammonium persulphate - it's my first time using this, as in the past I'd always used ferric chloride. It's nice that the ammonium solution is clear, as it makes it easier to see the process occurring.
Something I didn't expect is the requirement for some gentle heating of the ammonium solution for the etching to occur. With ferric chloride, the etching would occur at room temperature; the ammonium required me to place the etching container into a warm water bath (about 60°C) before anything appeared to happen. Agitation during the etching was performed manually with a small, soft-bristled nylon brush.

Here's the result, with the photo-resist still on the board
Copper etched, photo-resist still in place
The middle looks awful, because of what went wrong with the photo-resist. What's odd though is that there are specks of copper that don't seem to be covered by photo-resist, but haven etched away. The left and right areas look acceptable. The right has lost some of the numerals, but that was due to under-exposure at the photo-resist step. Wherever the photo-resist was, the copper has stayed, so that speaks well for the stability of that layer in the ammonium solution.

The next shot is with the photo-resist removed. This can be removed by abrasion, but I chose to use a caustic solution to remove it. I used a cheap oven cleaner product. A small amount sprayed on the board, and the photo-resist just brushed away.
Photo-resist removed
This shows how badly the center section has gone. The right side looks good - the tracks, at least. The left side SSOP pads look a bit "fat" in the top right. The bottom left looks "dirty" between the pads

Etched board - back-lit 
The back-lit shot reveals the true result. The left side does have unwanted bridges between the pins of the SSOP package, and the vertical lines aren't as clean as the centre and right, either.

Lessons Learnt
Overall, I'd say this wasn't a bad result for a first attempt - OK, so the result wouldn't have been usable if it were a real board, but I think that it was a valuable exercise as there are some things to take away from it for next time:

  1. Application of the photo-resist film needs more care.
    I think I rushed this, and there was wrinkling near the centre that has caused that part of the etching to fail. I was also concerned about the light sensitivity of the film, and rushed it. It's not that sensitive.
    Consider buying pre-sensitised board in future.
  2. Artwork sandwich needs more pressure
    There are some areas of the board that look like they aren't as sharp as others. Next time I'll add a piece of 3mm polystyrene foam to the back of the artwork stack to ensure the pressure is sufficient and uniform.
  3. Create artwork in reverse
    The artwork was used printed side UP, which meant that there was the possibility of light bleeding through the thickness of the transparency sheet. The artwork should have been printed in reverse image, and used printed side DOWN.
  4. Best exposure time seems to be around 2:30. More time seems less problematic than shorter, particularly where fine details are involved, but may be causing "fattening" of the traces. This may be alleviated by using reversed artwork (above)
  5. Closer inspection required at the developer stage
    Closer inspection of the board after the photo-resist developing stage may have indicated that some resist had not etched away. Another short dip in the developer may have resolved some of the final blemishes. Need to investigate how critical the development time is and whether more time will damage the exposed resist or not.

Sunday, November 6, 2011

Creating PCBs - Exposing the board

Now it's time to expose the photosensitive film to the UV light through the negative artwork mask. To get a clear image it's important that the artwork be held tightly against the board.
For this, I've used a cheap $2 plastic photo frame that I've cut down the length to fit neatly into the UV lamp. In this is (from the top)

  1. Glass (which I broke the corner off, cutting it down to fit the re-sized photo frame. OK, I suck at cutting glass)
  2. 1 sheet of rapidraw film, just to diffuse the UV light a little
  3. The artwork
  4. The copper board with photosensitive film
  5. A sheet of A4 paper, folded, to give the sandwich some more thickness
  6. The cut-down original backing plate of the photo frame.
It looks like this.


So this assembly goes into the UV lamp, like so:
And is exposed.

Exposure timing
I'd previously done an exposure timing test with the film, but not with the film on copper board. The exposure test is done by progressively covering sections of the film, and determining which section has been exposed sufficiently where the artwork is clear, but not exposed where the artwork is dark.
Too little exposure, and the film won't harden enough (with negative film, the exposed areas of film harden)
Too much, and the areas that shouldn't have been exposed may start to harden. This is why the artwork contrast is very important.
OK, so prior experimentation indicated that about 2 minutes should be enough. With this test board, I had three identical patterns, so I exposed one section for 2 minutes, the next for 2:30, and the last for 3 minutes.

This is the result:
From left to right, 3 min, 2.5 min and 2 min exposure
The vendor says that the film will darken where it is exposed, and you can see that is the case. In fact, at this point, it all looks quite good. Now to remove the un-exposed areas with the developing solution.
3 minutes on left, 2 minutes on right
Hmm, this shows some problems. The rightmost numerals have etched away in some cases. I'm not sure if it's due to underexposure, or if the film was not bonded sufficiently with the copper. The center top, I don't know WTF happened there - the only explanation I can come up with was that the artwork wasn't pressed well enough against the film, and some light has spilled? I would have expected the actual artwork to be blurry if that were the case, however. The leftmost exposure looks good.
The actual development of the film occurs pretty quickly (it's more of a "stripping" of the un-exposed regions), and I'm not sure yet what occurs if the film is over developed.

Next time, we'll see what the copper etching reveals...

Creating PCBs - Applying the film

The photosensitive film needs to be applied to the blank copper board before it is exposed through the artwork mask. But before that, the copper board needs to thoroughly cleaned - any skin oils or tarnished spots, and either the photosensitive layer will not adhere, or the etchant will not etch the copper protected by the oils. Both these are undesirable.

I've always cleaned copper board with a powder cleaner, like AJAX, and a scouring pad. The cleaner helps remove oils, and the scourer leaves a slightly "brushed" finish to the copper. The powder of the AJAX probably helps with that, too. Clean the board until it is uniformly bright looking. Oh, you should have cut it to the required size, before this step.

The vendor says that the film should be applied to the copper board using a hot roll laminator, but using an iron is an acceptable second option. The first trick though is separating the 3 layers of the film from each other. The photosensitive part is sandwiched between two clear protective plastic films - one of which needs to be removed before the photosensitive part is applied to the copper.

At first, I didn't believe the protective layers were there - they are difficult to separate, and even harder to see. The suggested method of getting them apart is to use a piece of adhesive tape to stick to the protective layers, then peeling them back. This does work, eventually, and you can pull back one of the protective layers.

Once one of the layers is removed, apply the film (unprotected side to the copper) from one end and work the film along with your fingers to ensure there are no air bubbles. Don't worry about working a dark room to do this - the film is not that sensitive. Conversely though, don't do it in direct sunlight.

When you're convinced there are no air bubbles, it's time for a press with the iron. Recommended temperature is 130°C, and maybe obviously, don't use steam! Also, don't use the ironing board as a base, as you want to apply a fair amount of pressure with the heat, and ironing boards aren't generally that firm. A flat piece of wood, like a wooden chopping board on a sturdy table is ideal. Place the board, copper and film side up, on the board, then a layer or two of paper, then apply the iron and press down for about 10 seconds.

That's it. The board now has the photosensitive film bonded to it, and the clear protective layer should still be attached to the top. Keep it somewhere dark and leave the protective layer in place until you're ready to expose the board.

Thursday, October 27, 2011

Creating PCBs - Generating the master artwork

The master artwork is the mask that is used to expose the desired pattern on the photo-resist material bonded to the blank copper board. Typically, it is some kind of thin film material that will block the UV exposure light in some places, while allowing the UV light through in others - resolution and contrast are the important factors.

The simplest way of creating this is to start with some kind of UV transparent film, such as an overhead projector transparency, and print the pattern to be masked with a laser printer. Provided that the laser printer can get enough toner onto the film, you should get a nice high contrast mask. Remember that if you are using negative acting photo-resist, you need to print a negative image; that is, black where the photo-resist is to be removed and subsequently where the copper will be etched from the board. Eagle helps to create the negative image by providing the PS_INVERTED device in the CAM process. The workflow I've come up with is like this:

Use Eagle's CAM processor to generate an negative postscript file. The offset controls on this window can be used to move the design within the page, but it also inverts all the area from the lower left corner, so it's wasteful of toner and ink. We'll fix that in a moment. For now, leave x and y offset both at 0.
Eagle CAM processor setup for inverted PostScript output
Next, edit the generated postscript file, and at this line, after the comment % set the origin:

      LeftMargin add LeftOffset add BotMargin add BotOffset add translate
Add in your desired offsets in inches
      LeftMargin 2 inch add LeftOffset add BotMargin 1 inch add BotOffset add translate

Now print the .ps file to your media. Only the area of the board (usually the "Dimension" layer) will be inverted.


Unfortunately, my laser printer doesn't generate very solid blacks. My inkjet printer (Epson WorkForce 840) generates a much better quality output, but getting the ink to behave requires the right media. Plain paper isn't UV transparent enough. I've tried a number of media, and here are the results:

  • A4 Tracing paper sheets - this is quite inexpensive, but it has a bit of a texture to it. It has areas where the density is different, so I think that may affect the exposure. The ink tended to soak and creep along the fibres of the paper, so the end result, although very black, wasn't as sharp as desired.
  • Rapidraw polyester drafting sheets - this is a very uniform polyester film. It's not clear, but a light grey translucent material. The output contrast was good, but it refused to dry. The other problem was that because the material does not absorb any of the ink at all, there tended to be too much, and it would bleed a little. Changing the printer setting may have helped. Here's a sample (for a sense of scale, the small numerals are 0.8mm high)
    Rapidraw film - too much ink on a base that doesn't absorb it at all
  • Inkjet overhead transparencies - these are the most expensive, and you have to use the ones designed specifically for inkjet printers. They have a coating on one side that assists in "capturing" the ink. It still took a bit of fiddling with the driver settings to get a quality print. This is the "plain paper monochrome" settings output. You can almost see each drop of ink, it needs more...
    Inkjet transparency - plain paper/photo/black settings


    This is the output on "best photo, gloss photo paper" setting...
    Inkjet transparency - Premium photo paper semi gloss / Photo RPM settings


    The only glitch with this is that the ink isn't drying quickly enough, and the paper exit feed rollers are causing that dotted vertical line near the "16". That can be solved.
Even though the transparency was coated, the ink was still "tacky" an hour after printing. This was solved by putting the printed transparency into the oven at around 65°C for 40 minutes to cure the ink better.

The same artwork creation process can be used to create the artwork to use with the UV curable solder mask paints. The only difference is which layers are configured in the CAM processor output, and whether a positive or negative master is required.

Next time, exposing the photo-resist on the PCB.

Wednesday, October 19, 2011

Creating PCBs - from design to finished board


Over the next few posts, I'll be looking at the processes involved in creating a finished printed circuit board using photoresist film.

I'll be using the negative photoresist film, as available from a number of vendors on eBay, but much of the process would apply equally to the positive acting materials available from places like Kinsten. I got the blank PCB, photo-resist film, developer and copper etchant from eBay.

The film is designed to be exposed with ultra-violet light. Typically, it's UV in the 365nm wavelength region. I'll be using a single 9W UV nail gel coating curing lamp, also from eBay. Seeing a pattern here? The lamp has a flat area of about 140mm x 75mm, which is large enough for the small boards I intend to make. For larger boards, there are 4 lamp versions of these available. The lamps used in these units are all pretty much the same, and are supposed to have their peak output at 365nm, so they seem ideal for this purpose. It should also be suitable for the UV cured solder masks that I see available on eBay - without knowing too much about manicure products, I suspect that the UV cured solder mask paint is very similar in chemistry to the nail gel coatings that are meant to be used with this lamp.

I've created a test PCB pattern in Eagle that I'll be using to see what kind of resolution I can achieve, and for exposure calibration. The pattern consists of 3 sets of:
  • 2 x SSOP 28 packages, which are far smaller than anything I expect to actually use
  • a 0.1 inch through hole header, for a sense of scale of a standard DIL package
  • some 608 SMD resistor pads
  • a series of lines from 10 to 50 mil (one mil is 0.001 inch or 0.0254 mm)
  • Vector text in two sizes: 32 and 50 mil (0.8 and 1.3 mm)
  • Some traces at 12 and 16 mil (0.3 and 0.4 mm), which seemed like reasonable widths for most interconnects. Perhaps a little narrow, but this is just a test to see how far we can push the process.

The first step will be printing this artwork in negative on suitable material to use as the exposure mask for exposing the photo-resist material. That's next post...

Tuesday, September 20, 2011

SoMagic EasyCap is no longer a (very small) boat anchor

Success in getting continuous video frames out of the capture device!

I can now stream 720x576 UYVY frames at 25 fps from the unit and pipe the output into mplayer, which can play them.
Obligatory screenshot follows (which doesn't do justice to the fact that it's motion video...but it would seem unfair of Carole Hersee to miss out, now she isn't cut in two!)
One full frame of test card F


I've posted the source code that you need to do this to a public github project easycap-somagic-linux . The code is incredibly rough yet, and there's plenty of to-dos on the list, but they will have to wait until I have more time. It's usable as far as I need it to be, for now.

I'm hoping that someone else will pick it up and turn it into a proper device and video4linux driver.


Friday, September 16, 2011

Vertical Hold

Isochronous problems sorted, using usblib-1.0 and the asynchronous API.

I now have every line of the field.
Just the problem of finding the vertical blanking period so that I can tell where the top of the frame is.
The 7113 indicates there is a bit field called SAV/EAV that should be setting a bit in the data stream to indicate the VBI, but it seems to be acting screwy.

Obligatory status pic:
Try the vertical hold knob...

SoMagic EasyCap - almost two fields

Continuing on with the EasyCap device, I've been able to generate some executables to initialise the device, and capture some video data.

This is the current best result, generated with "mplayer cap.out -demuxer rawvideo -rawvideo "w=724:h=460:format=uyvy"
SoMagic EasyCap capture of Test Ctard F - work in progress

It seems - unless I'm doing it wrong - that you need to manually find the horizontal sync markers in the video data. And the vertical sync, which you can see from the image, I haven't done yet.

The biggest problem I need to overcome is that what you see here is generated from 4 isochronous USB transfers of near 200kbytes each. There seems to be some kind of delay in fetching the data - evidenced by the three "cuts" in the vertical picture ( the second is in the vertical blanking section, so you can't see it)

I'm using libusb, and this is the section that captures the video data:

ret = usb_isochronous_setup(&isourb, 0x00000082, 3072, isobuf, 64 * 3072);
printf("195 isochronous setup returned %d\n", ret);
ret = usb_isochronous_submit(devh, isourb, &isotv);
printf("195 isochronous submit returned %d\n", ret);


ret = usb_isochronous_setup(&isourb1, 0x00000082, 3072, isobuf1, 64 * 3072);
printf("195a isochronous setup returned %d\n", ret);
ret = usb_isochronous_submit(devh, isourb1, &isotv1);
printf("195a isochronous submit returned %d\n", ret);

ret = usb_isochronous_setup(&isourb2, 0x00000082, 3072, isobuf2, 64 * 3072);
printf("195b isochronous setup returned %d\n", ret);
ret = usb_isochronous_submit(devh, isourb2, &isotv2);
printf("195b isochronous submit returned %d\n", ret);

ret = usb_isochronous_setup(&isourb3, 0x00000082, 3072, isobuf3, 64 * 3072);
printf("195c isochronous setup returned %d\n", ret);
ret = usb_isochronous_submit(devh, isourb3, &isotv3);
printf("195c isochronous submit returned %d\n", ret);

int r1,r2,r3,r4;
ret = usb_isochronous_reap(devh, isourb, &isotv, 1000);
//printf("195 isochronous reap returned %d, bytes: ", ret);
r1=ret;

ret = usb_isochronous_reap(devh, isourb1, &isotv1, 1000);
//printf("195a isochronous reap returned %d, bytes: ", ret);
r2=ret;

ret = usb_isochronous_reap(devh, isourb2, &isotv2, 1000);
//printf("195b isochronous reap returned %d, bytes: ", ret);
r3=ret;

ret = usb_isochronous_reap(devh, isourb3, &isotv3, 1000);
//printf("195c isochronous reap returned %d, bytes: ", ret);
r4=ret;

save_bytes(isourb->buffer, r1);
save_bytes(isourb1->buffer, r2);
save_bytes(isourb2->buffer, r3);
save_bytes(isourb3->buffer, r4);
Any clues anyone?



Thursday, September 15, 2011

The SoMagic EasyCap and linux

The short story is...it doesn't work. Yet.

The long story... is quite long. This is part of that story.

The EasyCap is a usb video capture device, or rather, a number of different devices. There exists at least 3 known variants:
1. The Syntek variant, with USB ID 05e1:0408 supported by this driver
2. The so-called DC60+ with an Empia USB bridge and USB ID eb1a:2861, which works with the em28xx driver included in recent Linux kernels
3. And lastly, the SoMagic variant, with USB ID 1c88:0007
All these are sold as "EasyCap", they all look the same, and if you're buying off eBay (where they can be had for less than $10AUD each ) it's a bit of a lucky dip as to which one you get.

I must be unlucky, as I got the one for which there exists no linux driver - the SoMagic.

Looking inside the device, and from the various reports, the unit is almost identical to the Syntek job, except for the USB interface chip.
These are the major chips inside:
  • SMI2021CBE - the usb controller device. Can't find a datasheet for this at all - the only info I've been able to find is this, and actually, that's for the 2020, not 2021. I'm assuming they're very similar
  • GM7113 - the video processing chip. Seems to be a clone of the Philips SAA7113. So this is the part that is the same as the Syntek unit.

An inital lsusb -v -d 1c88:0007 yields this:
Bus 002 Device 005: ID 1c88:0007 Somagic, Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x1c88 Somagic, Inc.
  idProduct          0x0007
  bcdDevice            1.00
  iManufacturer           1 Somagic, Inc.
  iProduct                2 SM-USB 007
  iSerial                 3 SMBL007
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           18
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              200mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)

So, if I'm reading this right... no defined endpoints. Totally vendor specific.
Interesting, on Windows using the supplied driver, the device doesn't even have that USB id. It's id is 1c88:003c. Clearly, the windows driver is doing some magic.
A usbsnoop and transform to a test program (instructions are here - brilliant! ) later, I can get it to show that device id in linux. Here's the "new" device's lsusb -v -d ...

Bus 002 Device 006: ID 1c88:003c Somagic, Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x1c88 Somagic, Inc.
  idProduct          0x003c
  bcdDevice            1.00
  iManufacturer           1  Somagic, Inc. 
  iProduct                2 SMI Grabber DEV
  iSerial                 3 SMIGRABBER9876543210
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           50
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x03ff  1x 1023 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       2
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x1400  3x 1024 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)
Aha! Now there are endpoints. I believe that this is closer to what the Syntek presents when it is first plugged in. The SoMagic must require this "firmware" to be uploaded to the initial device before it makes the second device available. There's about 7k of data that is uploaded in usb control messages.

Unfortunately, the Syntek driver doesn't work with the device after this initialisation. Things aren't where the driver expects them to be.

Investigations are continuing....

Saturday, May 14, 2011

Things to do when you should be doing Uni assignments #1

Just had a few spare (not really spare, just... quiet...) moments to look at the bluetooth serial module that a mentioned a few posts ago, and try powering it up.

As I didn't get any documentation for it, I used the documentation from the MDFly bluetooth adapter , as scant as that is for the pinouts.

After carefully soldering leads to pins 12 and 13, apply 3.3 volts. Via the multimeter. Set to milliamps. OK, current draw seems reasonable, and the current seems to be pulsing rhythmically - it's probably on the air. Let's check.
$ hcitool scan
Scanning ...
        00:19:5D:24:B7:63       OBDII
There it is. Step 1 done. Now, to send some data.

It took a bit of trial and error, but this is the magic linux incantation to establish a serial connection to the device:

$ bluetooth-agent 1234 00:19:5D:24:B7:63 & sudo rfcomm connect hci0 00:19:5D:24:B7:63 &
Agent has been released
Connected /dev/rfcomm0 to 00:19:5D:24:B7:63 on channel 1
Press CTRL-C for hangup

If that is successful, the device appears as /dev/rfcomm0, and you can write to it and read from it, like so:
$ ls -l > /dev/rfcomm0 & cat /dev/rfcomm0
Poking at the pins with the CRO confirms the data received is on Pin 1 (consistent with the datasheet ), so a far bet that Pin 2 is data to be sent. Bridging the two together confirms that whatever I send to the module from the PC gets echoed back. Sweet.

The bit period seems to be 25uS, which indicates 40kbps. The datasheet mentions 38.4kbps , so that's probably it, given the accuracy of this CRO is, well, poor.

So that's it - cheap bluetooth modules are go!

Wednesday, April 27, 2011

Memories...like the corners of my mind...

Don't recall how I stumbled upon this, but happened to see these in TransGrid's Network Management Plan on the web:
TransGrid owns 137 backup alarm systems that provide a combined alarm service as a secondary service to SCADA SMART alarm [ed: something missing here, TransGrid??]. It is a microprocessor-based system capable of transmitting and receiving 10 simultaneous alarms. SMART alarms currently account for the entire population of backup alarm systems in the network. This system has an expected life of 20 years.
 and
SMART Alarm transceivers have been installed as the backup alarm system. They provide a 10-function alarm service in both transmit and receive directions and have been designed to interface with all of TransGrid’s communications channels. SMART alarms currently account for the entire population of backup alarm systems in the network.
This system has an expected life of 20 years and at present there are no performance issues.

source: TransGrid Network Management Plan 2011_web.pdf  pages 55 and 68



The "SMART Alarm" was a project I completed back in 1997 while working at TransGrid. I don't recall how it came to be called the SMART Alarm...I think it may have been because it was microprocessor controlled, which was a huge leap forward from the op-amp filtered, 5-pulse-rate alarm system designed in 1982 that it was replacing.

The "designed to interface with all of TransGrid’s communications channels" means that originally, it was designed to work with 50 baud E&M signalling channels, over either a power-line carrier or microwave radio link. Yes. Fifty baud. You can almost watch the bits go by.

I still have a copy of the manual I wrote for it, which covered the basic theory of operation, installation and configuration.

From the Hardware Overview section of said manual:
The SMART alarm system is a 10 input, 10 output microprocessor controlled status transmitter and receiver built on a singe 220 millimetre length Eurocard board, designed to operate from a positive earth, 50 volt DC supply. As the system is fully microprocessor controlled, the flexibility of the system is limited only by the hardware constraints of the board, and what can be programmed in software.

I have fond memories of that project; developing the design, the PCB layout with Protel on Windows for Workgroups 3.11, writing the software for the 8051 in assembly language. Good times. PCB auto-routers have improved a lot since then, though. If I recall correctly, it was painfully slow.

So, a device installed in over 130 sites, with an expected lifespan of 20 years. And (to quote from the report) "no performance issues" as of 2011?

I must have done something right!

Thursday, April 14, 2011

Smaller and smaller and smaller

I didn't really appreciate how small these bluetooth modules are, until I got one delivered today.
The one I've got isn't exactly like the MDFLY one (linked above), but it's the same CSR BC417 chipset, mostly the same PCB layout - I'm pretty confident they're equivalent.
Which is lucky, because the ebay seller I bought this from sent no datasheet, and has none linked from their ebay page either. Good thing it was cheap. (about $8 AUD, delivered)

Saturday, April 2, 2011

Together at last

The CNC machine is together and working!
It's actually been together for a few weeks now, but I didn't get around to posting about it (because, what's the point of a post without video, right? )
Also, I wasn't happy with the aluminium slides I was using for the central plate, so I acquired some more 608 bearings, and replaced the slides with these.
Each of the slides are now a pair of bearings on a single bolt, separated by a thin brass washer. The lip of the extrusion on the CNC frame sits in the small V created by the gap and the chamfer on the bearing face. So there are now 16 bearings in 8 pairs bolted to the central plate.
I should have taken a photo. Oh well.

Here's the machine in action this morning...
 
and


And a photo of the finished product - just a scrap of chipboard, with "Amalie" now engraved in it. Blue chalk added so that you can see the routed letters.
Outstanding issues:
  1. The x-axis threaded rod must be bent, and it's causing a slight wobble when the x-axis moves. I think I'm just going to have to replace it.
  2. The central plate could be stiffer. You can still twist the x-axis a little. I may be able to increase the pressure of the rollers against the runners, but I think the plate flexing is the problem.

Monday, January 31, 2011

HobbyCNC stepper kit

The HobbyCNC Pro driver package I had on order arrived last Friday, so I have spent the week on and off assembling the driver board into the old UPS case that I had. It's a nice fit. I had planned on falling back on using a PC case, but with a bit of magic and luck, it all went into the smaller UPS case. I'm glad I persevered, as it's a really neat little unit when the cover is on.

The package includes everything needed, except the case and transformer. Luckily, the transformer from the UPS was suitable (not ideal, as the final DC supply to the driver board is ~ 22V. Ideally, it would have been about 35V or so, but the board will work down to 12V ). I don't know the exact specs of the transformer, but from the UPS spec (600VA output) and judging by the thickness of the low-voltage leads, I think it should be good for at least 10A of current. I'll be monitoring the DC voltage for droop once the CNC is up and running.

I got the largest steppers that HobbyCNC sell in the package - they are a lot heavier than I expected. I think there will be more than enough torque for most applications. Here's the first run, driven by Mach3 (took a while to get it configured to use the right parallel port address. Laptop was confusing it apparently)...



Having got the steppers running, I had to work out how to connect them to the threaded rod. I had expected to turn down (in a lathe) the end of the threaded rod to 1/4 inch ( the same size as the stepper shaft ) and then use a 1/4 inch shaft coupler. My mate Gordon (who has the lathe) came up with these instead...
Stepper - lead screw couplers. Thanks, Gordon!
8mm tapped on one end, 1/4 inch hole with grub-screw on the other. Perfect! Great work, Gordon.

Next post...should be the CNC machine assembled. I hope.

Tuesday, January 18, 2011

Just got 7oz in the mail

That's 200 grams.

Turns out the package wasn't the CNC steppers, but a pair of MSP430 development tools that I had forgotten that I had ordered from TI ( got them for free - thanks Dangerous Prototypes). They were dispatched from the Netherlands, surprisingly.
The MSP430 is an ultra low power, 16 bit microcontroller. These development kits are an integrated USB programmer/debugger with a tiny 14 pin MSP430F2013 attached to the end of the board. The board with the target processor can be separated from the end of the debugger, and the pins are bought out to reasonable sided pads.
USB case opened - close up of microcontroller end
There's also a LED on there, just top-left of the chip. There doesn't seem to be much on the micro side of the header, so you could probably use it as an in-circuit programmer too.

Now, what to do with them.... I'm thinking something solar powered...

Monday, January 17, 2011

I've been framed

The frame of the CNC machine is almost complete. I've gone with a "2 axis-of-movement table with a fixed Z axis" design.
It's basically two rectangular frames with laterally fixed threaded rods, which are threaded onto a central plate. The central plate is where all the adjustments for lash between the two axis are made with aluminium L-section glides. This reduces the number of bearings required down to just 2 for each axis. If it turns out there's too much friction for the steppers (yes, I've decided to go back to steppers), I can always replace the glides with bearings later on.

Here's the assembly before the z-axis verticals went on
The top frame will have a timber panel attached to it that will be the "work" surface; so it will move in the X and Y axis, relative to the fixed Z axis. 

This is a bit later on...
The router is attached to a timber frame that moves up and down the Z axis frame. This needs to have some aluminium slides added to it yet.

One of the hardest parts of this so far was working out how to attach the central plate to the threaded rod using just ordinary hex nuts. The problems here are: 
  • that the threaded rod is a little bowed, so the attachments cannot be totally rigid
  • I wanted to be able to disassemble the device reasonably easily
  • there needed to be some means of adjusting the lash of the nuts on the rod
So some device was needed that prevented the nut from turning, but allowed it move up and down as the rod rotated. Here's the evolution...
1st attempt - cut and bent L section.  
Ugly. And you can't get it apart without threading the rod right through it. And no lash adjustment.

2nd attempt. Three small L sections screwed together.
Better, but a pain to make. The nut slides in (tightly) between two of the L's, the third one takes the lateral (?) force. Seemed like that wasn't going to be rigid enough - the L section was wanting to bend when a reasonable amount of force was applied. But it was good in that the lash could be adjusted by sliding the rod out of the holder, turning the nut 1/6 of a turn, then sliding it back in.

3rd try. Channel with a cut and bent in 12mm section.
This is what I settled on. It's aluminium channel with a 13mm internal width. The nut is a snug fit in there. The walls of the channel are cut 6mm deep, 12mm apart, then bent in slightly. These are where the lateral force is applied from the nut to the channel.

So that's it for now. The stepper motors and control board have been ordered (actually, FedEx tried to deliver them today). I got the HobbyCNC PRO kit with 305 oz-in motors. That's almost 22 kg-cm of torque, if the online calculators are right. That seems like a lot. Guess we'll see...