cyborgworkshop.org

I just made hackedgadgets.com !

Got the first servo online tonight.  Check out the project updates for pictures.   The outdoor sensor is having some direct sunlight issues, so I’ve made a blind for it, but the foam is still drying so may not see it until tomorrow.

This week we’re going to try to knock out a few WHIA todos.

• Build the servo mounting plates. I’m thinking about 1/16 aluminium plate or possibly lexan (cheaper)
• Build the servo arms. The cantilever system was just too complex for such a simple job.
• Mount the servos up!
• Wire them into the controller.  Only problem is that Im out of wire and that stuff isn’t free, Click those google ads people
• document document document

The micro PC arrived today. It’s a Via C3 based Mini-ITX board in a custom case that I scored off of ebay for $50 brand new, never opened. It looks like it used to be a VPN appliance from some failed .com. Plenty small enough, but now that I’ve changed the code around, I don’t think it’s needed anymore. I’m going to keep it handy, but no PC is less complex and less power consuming then a small PC.

It looks like I do have a direct sunlight problem with my outdoor sensor too, so I’m creating a shroud out of a kitchen funnel and some great stuff foam.  I’ll post pictures of that tonight or tomorrow once the foam is dry and I’ve got it mounted up.

This whole USB port reset thing is starting to annoy me.  I think my usb cable is just too long and is picking up a lot of EMI which causes my host computer to see a USB hub reset and it disconnects the FTDI port emulator. When that happens, it comes back as a different device node (USB1 say instead of USB0) which causes my code to stop reading which causes those big chunks of blank data.  I have two work arounds. The first is to put a very low power PC near the controller that will act as the host PC instead of one of my servers in my computer rack. That method eliminates the long USB cable, but we could still have a problem if my resets aren’t coming from the cable length but from the controller.

Option two is to add in some check logic into the script that will make it first look for which device the arduino is on, perform it’s read and then exit after X number of reads. that way, if the device changes at any point, it will be picked up by the next run of the script and it should always be able to pick out where the arduino is.  The problem is that I need to update the rrd databases every minute. It takes me 1 second per sensor to get a value and, sometimes, sensors just don’t’ respond and I move on. I have 6 sensors currently  and have discovered that if I force the script to exit only after 30 good reads total, I have at least 5 opportunities for a misbehaving sensor to respond and the whole process comes in under 1 minute. That means I can move the script from being run nonstop to being called out of cron, which is a good thing.

As for now, the code has been updated and is running, the PC has been ordered but may end up being a buyers remorse purchase. We’ll see.

I have this perl script called Get_Temperature.pl that has been giving me fits. It simply reads a serial port that gets updated every second and does some regex on those values. The script was slowly consuming more and more CPU over time and creating a huge backlog of data. By the time it had run for an hour, it was at 60% CPU. To help troubleshoot, I wanted to output the amount of CPU that the script was using every time it processed a string, so I used this.

ps -o pcpu,pid,user,args -C Get_Temperature.pl

the -C flag allows me to specify the process name instead of a PID and the output looks like this

%CPU PID USER COMMAND
0.0 1075 jason /usr/bin/perl ./Get_Temperature.pl

Quick, low impact and works.