This morning I was in my backyard when I heard a vehicle pass in the alley behind the fence. I heard the vehicle stop, accelerate, followed by crunching and banging noises. I quickly ran to take a look and found this scene: a large pickup truck was halfway into my property and had run over my garbage can and my "No trespassing" sign. The guy came out, I yelled at him and asked what he thought he was doing, and his response was: "Oh I'm sorry, I was trying to back into my yard and I didn't see that." You "didn't see that"??? Now I can maybe understand not seeing the little sign, it might have been behind the garbage can, but what about the garbage can you were also running over? What if either of those would have been my kid? Would you have seen him???
Thanks to a grant from the wonderful city of Longmont, Colorado, the Tinkermill maker space recently was able to acquire a Neoden TM245P Pick and Place machine, which will be a great asset to the various businesses based there that need electronic prototyping capabilities (including mine!: Silicognition LLC, LiFePO4wered.com). In collaboration with Ted from Funovation, we cut a solder stencil using standard transparency film on Tinkermill's new 80W laser cutter, and did a quick test build of one of Funovation's boards.
The build went quite well for a first try. It takes some fiddling to get the build file generated just right, especially to get the pick positions calibrated correctly. I'm hoping that once we figure out pick offsets for different standard size components, this part should become less time consuming. As can be seen in the video, we were able to load the microcontrollers from a piece of cut tape by taping cover film from another reel to the tape's own cover film and feeding that through the peeler.
We then used our new T-962A reflow oven to reflow the solder.
I had to run the board twice and use a profile with a higher peak temperature to get the solder paste to reflow. This is another thing that we'll have to fiddle with to get just right. The transparency used as solder stencil was thinner than it should be to lay down a nice layer of paste, and I think this contributed to our reflow problems. The resulting PCBs look like they should work, but the connections would definitely be better with more solder. Some pads aren't even completely covered.
The micros were also shifted up from the ideal location, and since we didn't have enough solder for surface tension to do its job straightening stuff out. Still, not bad for a first test!
I'll need to work on getting placement accuracy better before I can build some of my LiFePO4wered/USB panels. For those who use Eagle, you can find an adjusted placement export script that works with the TM245P on Github. Happy picking and placing!
I recently have been working on several projects that involve Bluetooth Low Energy, a.k.a Bluetooth Smart. I was looking at using a Dialog Semiconductor DA14580 based module in an upcoming design because of its low cost, low RX and TX current and small footprint. I was curious however how the low current consumption would affect range, so I decided to run a little test using some development boards and modules I had laying around.
Mind you, this test was extremely unscientific, so take the results with a grain of salt, or rather, a whole salt shaker. I basically just spread out a bunch of boards on my desk with little regard for antenna orientation etc. and used my phone (a Nexus 5) to check at what distance I could pick up each module's advertisement signal. Distance was estimated using steps, afterward recalibrated using an aerial view and scale from Google Maps. All the modules were used at their default power settings.
|Cypress Semiconductor||CY8CKIT-142||PSoC 4 BLE||25|
The distance was not measured in open space, the signal originated from my desk, had to go through a wall and two metal door frames and a glass door. I also did not check if the default settings for TX power for each of the BLE modules was similar at all. As I said, a very quick test to see how the DA14580 compared to the others.
Obviously the range of this chip is less, but I was actually happily surprised to find that it worked as well as it did. I think it's a pretty decent range in far from ideal circumstances, considering the low current consumption of only 5mA in TX and RX.
So often when electronics need to be added to a project, you hear "we'll just add an Arduino". Many sensor and other breakout boards are labelled "for Arduino", even if they work just as well (or better) with any other microcontroller. Arduino sure has built up a brand that few in this space can match. Is it deserved?
I have a new project: LiFePO4wered/USB. Also a web site to go with it: LiFePO4wered.com.
I decided to put this here just as much as a reminder to myself as for the benefit of others. :-)
The CC3200 is a pretty neat new WiFi chip from Texas Instruments: It contains two CPU's: one running the TCP/IP and WiFi stacks and the other one (an ARM Cortex-M4F) is available to the user to run his application. When I tried to figure out if development was supported on a Linux host, I got mixed messages. On the one hand, TI's CCS IDE is available for Linux, but on the other hand, the CS3200 SDK comes as a Windows executable.
I was trying to set up remote access to the LAN of an OpenVPN client, by configuring the OpenVPN client as a gateway. There are plenty guides online on how to do this, such as this one. In my setup, I was using a Netgear router, with a Raspberry Pi connected to it acting as the OpenVPN client and gateway for the LAN. I followed the setup carefully, but was frustrated to find it didn't work. The VPN worked fine: I could access the Raspberry Pi remotely, both on its VPN IP and its LAN IP addresses. Still, I could not gain access to the LAN it was connected to, even though I had set up a static route in the router to send all VPN traffic to the Raspberry Pi.
After breaking my head over this for a long time and getting very frustrated, I finally figured out what was going on. I needed to enable IP forwarding on the Raspberry Pi! To do this in such a way it is configured correctly at boot, uncomment the following line in /etc/sysctl.conf:
That's it! After that, my setup worked beautifully. Hopefully this will save someone else some time and frustration. :-)
Every now and then, articles pop up about how archaic text based source code is, and how everyone would benefit so much if we'd all switch to graphical code design by dropping little boxes and connecting them with wires. We've heard this story so often before, and yet source code is still the preferred method to write software. Why? There are so many reasons, and they should be obvious.
Sometimes you create beautiful projects, and they don't work. Then there are times you make something that has absolutely no right to work, but it does. This little project falls into the latter category.
My name is Patrick Van Oosterwijck. Welcome to my spot on the web where I will hopefully regularly dump some of my brain content for the benefit of whomever may find it useful.