www.jaycrowe.com

I would just like to say, at this point in my work day, having gotten only one built so far, that I will destroy whoever designed that USB connector.

That is all.

Oof, okay. Unless I can do something about my process, this is going to be unsustainable It's taken me hours to do... five. Each one required substantial rework--STILL bridges on the 32u4 (!) and lots of problems with that old USB connector; had to remove/replace them a few times (one board turned out great but was then a loss when it fell while attached to the test fixture and landed on the USB connector, which snapped off the solder pads on the board... sigh).

I'll make a few more and use the rest to teach a SMD reflow class maybe. Hopefully the new USB connector (whatever I decide on) will fix that particular issue. Either that or if it scales enough I could just pay someone to do it

Hi Vic,

I'm soldering fine-pitch SMT's not with paste and heating or reflow, but with 0.3mm solder wire and a sharp tipped solder-pen without problems.

Removing SMT-IC's is easy with a thin nickel sheet (e.g. from radio-security-tags) with pushing it under the pins while heating them with the solder-pen ...

Viktor

Actually, I'll say this: that cheap little hot-air rework station does a decent job of pulling the chips off with a little bit of time. I was able to fix all the problems--there just shouldn't be problems (and I'm not convinced about the security of the USB connectors; I'll feel better when I can use one that has legs and holes for strain relief).

I'm just trying to figure out what is different between what I'm doing and what Sparkfun did when I took their stencil class--TQFP with no bridges at all, no trouble. It must have something to do with how I'm using the stencil (it's not as "clean" as it should be when I pull the stencil up; maybe I'm putting a little too much pressure on it and forcing paste under the stencil somehow).

vputz wrote:Each one required substantial rework--STILL bridges on the 32u4 (!) and lots of problems with that old USB connector

Are you using a different kind of solder paste than what Sparkfun used?
I'm wondering if yours has less flux? Or are you using too low a temp w/ your reflow plate?
Even if you didn't pull the stencil up cleanly, the flux in the solder paste should flow off the solder mask and the solder should stick to the metal.

Sounds like VDX is doing the typical hand soldering technique w/ lots of flux and drag soldering (though I'm surprised he's not doing it w/ a conical tip) and that technique won't work w/o a solder mask.

If you want a more solid microusb connection, I don't see anything better than that vertical thru-hole microusb connector I found. If you still want to use the surface mount microusb connector, I'd seriously consider trying that one w/ the cutout in the back. Soldering the grounds will still suck, but the other pins are more accessible.

When the bridges happen, they always are "up the legs" a little, which is what made me wonder if I was just applying too much. I may well be using a different solder paste; I wasn't particularly well-informed when I bought it (http://uk.farnell.com/jsp/search/produc ... SKU=149968; it's also worth admitting that this tube is a little past its "expiration date"). I'm also using a no-clean flux pen, which probably isn't doing a particularly good job... I've tried fixing a bridge with flux and dragging, and that succeeded in bridging almost an entire side of the chip.

But hey, these hiccups are how you learn after all. I'll try another batch of 4-6 today.

Well, did a little experiment today; made 4 boards and took stencil vs finished. I'd thought stenciling was more permissive with reflow, but it was really clear: if I nailed the stencil, I got a good board, but if it was off just a bit, I needed rework. For example, this paste, which missed the pads a bit... ...did indeed result in the following solder bridges:
...whereas getting it dead on even if it looks like it's getting out a bit...
...made a nice clean reflow (pic next msg)

...this is what I'd rather see:
Second big adjustment was evening out the height around the PCB on my stenciling "board" (a cutting board with pieces of perfboard arranged around the central PCB). This made a bigger difference than I had imagined it would.

So anyway, I do have 9 built and tested, and a few kits as well; I'll build another 6 boards when I run a reflow soldering class at the local hackspace (which should be amusing and maybe a good way to learn even more--and if I don't get 6 signing up, I'll have a "smd kit" or two). Initial response from the testers semes to be that it works OK, so I think we're just about ready to roll.

vputz wrote: I'm also using a no-clean flux pen, which probably isn't doing a particularly good job... I've tried fixing a bridge with flux and dragging, and that succeeded in bridging almost an entire side of the chip.

For this, you really need to use a conical solder tip for it to be almost brainless easy. The middle of it sucks the excess solder away as you drag it.
I also use a water cleanup flux pen w/o issues.

I'm wondering if it really is stale solder paste...even excess solder should magically suck itself onto the pins when you heat it up if the flux in the paste is working properly. I think the board has to be horizontal though (not-tilted).
See if you can try different solder paste at the next hackspace.

For folks who haven't done it before...the orbotron 9000 github page (https://github.com/thingotron/orbotron_9000) says install the arduino IDE, but doesn't specify that under Tools/Board in the menu, you have to specify ATMega2560; if you don't do this, it'll say "Serial1 not defined in scope". You also have to select the serial port under Tools/SerialPort (mine was COM6 but when you plug in the board, it should show up as a specific port and you should only have a single choice that's non selected). And under Tools/Programmer, choose Arduino As ISP.

That got me up to the point where it compiles, but can't seem to find the headers:
=============
In file included from GainDemo.ino:1:
J:\Win32Dev\Arduino\libraries\Orbotron/orbotron_device.h:11: error: 'JoyState_t' does not name a type
J:\Win32Dev\Arduino\libraries\Orbotron/orbotron_device.h: In constructor 'Orbotron_device::Orbotron_device()':
J:\Win32Dev\Arduino\libraries\Orbotron/orbotron_device.h:17: error: 'joy_state' was not declared in this scope
J:\Win32Dev\Arduino\libraries\Orbotron/orbotron_device.h: In member function 'void Orbotron_device::send_joystick_report(short unsigned int, short unsigned int, short unsigned int, short unsigned int, short unsigned int, short unsigned int, short unsigned int)':
J:\Win32Dev\Arduino\libraries\Orbotron/orbotron_device.h:34: error: 'joy_state' was not declared in this scope
J:\Win32Dev\Arduino\libraries\Orbotron/orbotron_device.h:41: error: 'Joystick' was not declared in this scope
J:\Win32Dev\Arduino\libraries\Orbotron/orbotron_device.h: In member function 'void Orbotron_device::send_keyboard_report(unsigned char, int, unsigned char*)':
J:\Win32Dev\Arduino\libraries\Orbotron/orbotron_device.h:46: error: 'Keyboard' was not declared in this scope
J:\Win32Dev\Arduino\libraries\Orbotron/orbotron_device.h: In member function 'void Orbotron_device::send_mouse_report(unsigned char, char, char, char)':
J:\Win32Dev\Arduino\libraries\Orbotron/orbotron_device.h:59: error: 'Mouse' was not declared in this scope
============

Which I did put in J:\Win32Dev\Arduino\hardware\orbotron.
I tried moving it to J:\Win32Dev\Arduino\hardware\arduino\orbotron as well w/ no luck.

Any other testers hit this issue before? Nothing in the arduino preferences seems to show you the path to your library that it's using. I guess they're trying to mask everything so it's easier to use but I want to see where it's looking

Kenyee--

Actually the way this should work is just the way it says on the github readme:
...in other words, if the install went correctly, under tools/board in the menu, you should be able to choose "Orbotron 9000". The reason to do that (rather than just choose Leonardo or the 2560) is particularly important if you have to reburn the bootloader, but I suspect that's the reason you're having trouble. It's finding your libraries fine (although usually additional libraries are installed in the user's library dir, but that's personal preference), but it's not finding the core files for the Orbotron board (again, usually in arduino/hardware/orbotron).

So I'm quite puzzled by the problem actually! What should be happening is the Arduino environment scans the hardware directory and subdirectories looking for boards and variants (listed in "hardware/orbotron/boards.txt"); when you choose the "Orbotron 9000" board, it adds the appropriate directories (hardware/orbotron/cores/orbotron...) to that project for compilation.

Hm. Puzzling. I'll take a look when I boot back to Windows.

Did I ever tell you I'm not great at following directions?
I installed the latest Arduino 1.5.2 nightly so I could try the Arduino Due (ARM based Arduino).

They've apparently moved thing around quite a bit, so under hardware/arduino, there are now different architectures.
To get the basicjoystick sketch to compile, I did the following:
- moved the hardware\orbotron directory over to hardware\arduino\orbotron
- copied hardware\arduino\avr\platform.txt to hardware\arduino\orbotron and renamed the "name=Orbotron AVR Boards" up top
- added "orbotron.build.extra_flags=-DUSB_VID={build.vid} -DUSB_PID={build.pid}" to the bottom of boards.txt so that it won't complain that USB_VID is missing.

Compiles fine, but it gives a cryptic error when doing the upload:
Binary sketch size: 14,770 bytes (of a 28,672 byte maximum) - 51% used
processing.app.debug.RunnerException
at processing.app.debug.BasicUploader.uploadUsingPreferences(BasicUploader.java:127)
at processing.app.Sketch.upload(Sketch.java:1670)
at processing.app.Sketch.exportApplet(Sketch.java:1604)
at processing.app.Sketch.exportApplet(Sketch.java:1576)
at processing.app.Editor$DefaultExportHandler.run(Editor.java:2424)
at java.lang.Thread.run(Thread.java:619)
which makes no sense since the BasicUploader.java file is no longer in the arduino source tree.
Filed a bug w/ the Arduino github project because RunnerException should print out the error it sees: https://github.com/arduino/Arduino/issues/1446

You'll hit this problem eventually...1.5 will be released soon. I'll fiddle w/ it a bit more before trying the older IDE.

That's why I wasn't mucking about with bleeding-edge builds This sort of thing is one of the reasons I was shy about using the Arduino environment (it bit me a few times with the shield), but when it does work it's very seamless and easy to deal with, and the worst-case scenario is "oh, just make a parallel installation of the old version" (since it's unlikely that anything someone does with the Orbotron is going to need newer features).

But I appreciate the heads-up, since it's always nice to make it work with new versions (and you never know; a far future version may replace the ATMega with one of those cute Nordic Arm/Bluetooth SOCs and ditch the cable entirely!)

For now, I just need someone to test the store and we can get some of these into the wild!

Just my 2 cents. I d/l the arduino enviroment 1.0.3 as per installation instructions for orbotron 9000.
I then copy/pasted the Orbotron directories as per installation instructions.
I plugged in the Orbotron 9k and checked the COM port in device manager.
I started Arduino 1.0.3 and set the COM port to what I found in the Device Manager.'
I selected Orbotron 9000 as board type as per installation instructions.
I was then able to compile and upload the various test sketches found in the examples
folder, as per the installation instructions.

rayz007

P.S. Did I forget to mention the installation instructions?

Haha... But I'm glad the instructions seem sound! I did manage to borrow a "Hackintosh" for the weekend to test whether it works under OSX, but unfortunately I neglected to get the password, and the guy I borrowed it from isn't answering his phone.

I did make a bootable Ubuntu drive and it seems to work fine under Linux... mostly. It generated appropriate HID messages ("cat /dev/input/js0") generated the right responses with jstest, and was detected under SDL. Unfortunately it would lock up after a while, but I can't tell if that's the device or dodgy USB support with this particular netbook. If I have more time I may reboot into my gentoo partition and see how it is.

Actually, hang on... I have a rackmount server over here with a USB port... yep, jstest runs fine and seems solid, so I think it's just the laptop. Not sure what that bodes for testing it on this laptop in OSX mode. Hm. But it does seem stable in linux at least.