I started a new small project. I am calling it bbps (Bread Board Power Supply). I realize there are quite a few of these out there already. They are all missing one thing that would be a REALLY nice feature. USB data line pass-through. Maybe it is because I am mostly interested in making PC peripherals but I am somewhat surprised that there is nothing out there already that has the feature set I am looking for. A good potion of this design is straight from my loststone project.
Features I am looking for in a breadboard power supply…
- Independently selectable 3.3V and 5V for two power bars.
- Optional shutdown a single power bar.
- Provide power from both a wall wart or a USB connection.
- ESD protection. (I think I went a bit over board on this front)
- USB data line pass-through
- Stable. Don’t want it flopping around.
I have place the OSHPark order and will be placing the Mouser order shortly
Two years of blood sweet and tears and it has finally come together! A fully opensource trackball from circuit board to software.
Check out the project page for more details.
Took some time off. Been quite busy. That and I was having some issues and needed to step back.
Tonight I messed with the CPI values a bit and removed the multiplier. The multiplier works well on the desktop but in games it makes movement… strange. But the big win was replacing the 100 pF capacitor on the MC14490(debouncer) to a 1000 pF capacitor. This slowed the oscillator allowing for more time between register shifts in turn allowing for a longer debounce period. This change fixed all my bounce issues! I still want an oscilloscope to actually see the bounce and how the different debounce methods affect it. I am just guessing, which I don’t like doing.
So i have been using a 1.5″ x 3.5′” PVC reducer as the housing for the motion sensor as well as the stand for the billiard ball. I really could not ask for anything better. The one problem i always had was the distance between the motion sensor lens and the billiard ball According the ADNS-9500 technical manual it should be at a distance of 2.4 mm with a tolerance of +-0.22. Really? 0.22 mm tolerance. I realize in the grand scheme of things a tolerance of four tenths of a millimeter is really not all that precise. However its not really possible to eyeball that. I was having trouble getting a good measurement so I created a cutout. I have always really like cutaway models. So after creating the cutaway I was able to get some accurate measurements. It turns out I need to cut the upper PVC ring so it has a height of exactly 8 mm.
So I have been using the loststone prototype for about a month, I have only been using my store bought mouse when I screw something up 🙂
Aside from the occasional physical issue, mainly the buttons falling off, I have only been having one issue. Sensitivity. If I set the CPI high enough(ex 4500) for the courser to travel the full length of the monitor with a reasonable spin of the ball, It is next to impossible to move the courser over a specific character on the first try. Some times even the 4th or 5th try, VERY annoying. Setting the CPI low enough(ex 540) for really nice small movements and it takes multiple turns of the ball to move the full length of the screen.
I originally thought that some very complicated math would be required to solve this issue. So I figured I would start out small to get an idea of what I needed to do to accelerate the courser across the screen when moved fast enough and yet still allow small intricate movements. Much to my amazement the first equation I came up with did exactly what I needed it to do.
After some tweaking of the denominator and CPI values I came up with the CPI at 540 and the following equation.
f(x) = ( |x| / 40 + 1) * x
||f(x) = x
||f(x) = ( |x| / 60 + 1) * x
||f(x) = ( |x| / 40 + 1) * x
||f(x) = ( |x| / 20 + 1) * x
The red plot is the raw sensor input(both x and y coordinates). The rest are different values for the denominator, I am currently using the blue one.
One of the reasons this works so well is the way that rounding is done when casting a float to an int in C++. Well actually there is no rounding. For example if we solve for x = 6 we end up with 1.15 * 6 = 6.9 which when cast to and int is simply 6. When x = 7 we end up with 1.175 * 7 = 8.225 which then becomes 8. So the 6 smallest movements are not actually changed. And when the values do start changing it is a smooth progression to larger numbers.
So I have been using this as my primary pointing device for about a week now. I have changed the button position and stylish clay palm rest close to 30 times. There still not exactly where I want them but its close enough where I can now start figuring out how I’m going to mount the buttons.
The motion of the call is working better than I ever expected it would. Its as smother than any trackball I have ever used. The Z-axis is still a bit wonky for some apps. Currently when you press the left bottom “button” it changes the CPI from 5040(max) down to zero(min) and uses the X-axis value as the Z-axis value
Originally I had set up a “PinDetect” object for each button to debounce them. This worked fairly well but no matter what values I changed the frequency and sampling numbers to I could always get either clicks that did not register because i clicked to quickly or clicks that registers more than once because the bounce was to long. Even if i could get it working as i wanted to as a programmer I have never been a fan of polling. Its generally a waist of resources and in some cases lead to unexpected behavior especially when there are going to be 6 or so polling so tightly(~20ms). I just don’t like breaking the program flow like that. I realize the MCU is complete overkill for a trackball and I have more than enough ticks to spare.
Because of my aversion to polling like that on my last Mouser purchase I added a MC14490PG from ON Semiconductor. The chip is ludicrously expensive at $4.77, hell the LPC11U24 MCU was only $3.92. However it was easy to wire up and in my opinion a more elegant solution, and so far I have not seen any unwanted behavior. There where few other debounce solutions I read up on and may test out, but for now the MC14490PG it is.
Though I would still like to get my hands on an oscilloscope. It kills me not being able know what is actually going on when one of the buttons is pressed. If I knew how long, on average these switches bounced for I might have been able to fine tune the “PinDetect” objects better
On another note I came across Dialight, which among other things makes SMD LED‘s and light pipes, lots of them! (What can I say odd things excite me 😀 ), Mouser/Digikey even have them in small quantities. Not even sure if I am going to do anything more than standard 5mm/2.5mm round LED’s but its nice to know the option is there.
Well after a very long break I finally ordered a custom PCB from OSHPark. I am very pleased with the result, i needed to manually cut the board because had my cutouts on the wrong layer. I am most impressed with the fact that I soldered on a MOSFET with .5mm pad the first try! After putting all the components on the board and rewiring the breadboard it worked. Hell yes. My code was all wonky and its completely unusable but the hardware is functioning.
On to some code clean up.
To make the base for the ball of my prototype trackball I went to Homedpot and got 3″ to 1.5″ PVC bushing and a 3mm Teflon rod from McMaster.com (Damn that’s an awesome site) and assembled them like you see in the picture. This was a complete failure. There is some serous resistance when moving the billiard ball. I tried flat and pointed Teflon nubs with the same result. I am not sure what I am going to use in its place but I am thinking a hard smooth metal of some sorts. Its funtional so i am leaving it the way it is for now.
It never occurred to me to check the pitch of the ADNS-9500, which is a problem since its 1.78mm and almost most everything development or prototype related is 2.54 mm.
It doesn’t actually do anything but I can plug it into a computer and it registers as a USB device. The computer has no idea what to do with it but it at least knows it exists. I know I wired at least two parts worse then correct but better than wrong, since it seems to be working. I need to read up on this a bit more.
As far as the code, I used stock example code for a generic HID from NXP. I literally did not change a single character of code and loaded it with the LPCExpresso IDE in Windows. It actually says “LPC 13XX USB HID” in the lsusb output.
Its not much but i accomplished what i set out to do yesterday, which was simply to see if i could get a computer to see something coherent from this dev board.
Shortly after I got my first computer I purchased a Logitech TrackMan Marble FX Trackball and it was glorious.
For almost 10 years this was the one and only mouse/trackball I ever used. I went through a few of them. I found the sensor cover would eventually fall off the the tracking sensor would get full of gunk and stop working. I even went as far as to stock up on them after I heard they had been discontinued. unfortunately about 5 years ago my last one gave up the ghost.
Since then I have bought and/or tried out quite a few trackballs. None of them have ever come close, there was nothing particularly wrong with most of the them, they where just not the same, they where all missing at least one key feature I could not do without.
So I have decided to take it upon myself to create a trackball that(hopefully) fills in the gaps that the bin of trackballs on my shelf could not. To be honest I may be biting off more than I can chew. We shell see.
Design points I am shooting for.
It should be relatively simple to fully disassemble in order to completely clean every piece. I would consider myself just as clean as the next guy by I find that all my HID’s eventually get absolutely filthy. Most of them are quite difficult nay impossible to really clean well.
The technical specs should be on par with the best high precision mice/trackballs on the market. Not only that but all the physical pieces should be top notch.
- Big Ball:
I was actually thinking of a Billiard ball(56mm).
You can never have enough buttons.
All code, designs and anything else related to this device should be under an open source license (have not decided which one).
I have already done quite a bit of research and picked out the first two major components. For the motion sensor I am going with the Avago ADNS-9500. This was the best sensor I could find and it seems fairly straight forward to get working. For the MCU I am going with the NXP LPC1343. Since I don’t have any experience with MCU’s this was a fairly difficult decision. In the end I decided on NXP because of the documentation, the user community and the fact that there is open source drivers under the BSD license. I decided against the mbed primarily because a lot of the work is already done for you. The knowledge I gain from this is just as, if not more, important than the result.
My order from Mouser is on its way. I am quite exited I have not had a good project in quite some time.