Monday, April 28, 2014

DSLogic unboxing

Today, my DSLogic came in the mail. For those that don't know about it, it's a logic analyzer with the ability to act as an oscilloscope and a DAQ.

Here are the unboxing pictures for those that want to follow along with this review. Note that I haven't actually gone and analyzed anything, so that review will come later.

The first thing I noticed is that the box that the logic comes in looks nice, but isn't going to make a nice case for it at all. I would have rather had a nice case that all of the probes and everything would fit into that I could carry around. It has four phillips screws on the bottom, so if anything goes wrong with it, at least the case is openable. There's a little hole for an LED, that really needs a lightpipe because it's down inside the case. I'm sure it will still be visible, just not diffused as well.

After seeing some other reviews,  I checked the cables to see what they meant by the poor quality. I hate to confirm that they're correct, but they are. The wires are very thin, and seem breakable. I know that eventually some of them are going to break.

I really am not fond of the clips. The first thing I noticed is that the part where the wire attaches isn't only in the center back of the clip, but that the pin was at an odd angle. After bending it back, it hooked on decently well, but not as well as I'd like. I prefer the pin to be off to the side of the clip so that I can press on the clip with my thumb completely. Also, in the last picture, I notices that the probe uses more of a claw mechanism, rather than the hook that I've seen on previous probes, so I don't think it will hold onto the pins as well.

That's all for now, but I'll add more posts once I start using it.

Tuesday, April 8, 2014

BotQueue and Heartbleed

Have no fear, for the system is secure... well... almost. It's currently not vulnerable to Heartbleed, however we need to get new private keys because we have no way of knowing if they were compromised.

Looking at what information I have available, it doesn't seem like anything was really attacked, but then again, it's almost impossible to know with the heartbleed attack.

Zach Smith will have to regenerate keys for the server just in case they were compromised, but it looks like everything updated correctly and no one was affected. If you were affected, please let me know immediately!

 According to SSL Labs, we currently have an A- rating because of 2 issues I'm still working on improving.

Enjoy using BotQueue knowing it's secure!

Monday, January 20, 2014

BotQueue for Windows

A long standing issue is that BotQueue's client bumblebee doesn't work on Windows. I'm going to try to fix that with this blog post.

I started by looking at Portable Python version 2.7. Note, that I'm installing this all on an 8GB flash drive. There's two reasons for this. The first is that I want to test this with multiple computers, and the second is that I don't have admin privileges on any of them. Go ahead and run the installer, it takes a while.

Next thing to download is easy_install so I downloaded onto my flash drive and ran it using the python I had just installed:
It might tell you to run a different command. I ended up having to run:
python.exe -U setuptools 
Next, add the "Scripts" directory under your App folder to your PATH variable.  For me, this was at "E:\Portable Python\App\Scripts". You should also add the App directory so python can be found anywhere. You know it worked if you can run "easy_install" in the prompt and it not completely fail.

Next, install pip and virtualenv:
easy_install pip
Now that pip is installed, open up a command prompt. Run this:
pip install Pygments pyserial requests requests-oauth
pip install pyserial --upgrade
Next, we need to install curses for windows. Go here, and download the win32 2.7 one. I ran this to install curses:
easy_install curses-2.2.win32-py2.7.exe
Now run botqueue's bumblebee client! You'll have to run my version here, instead of the official botqueue (until that branch is merged, so if the branch doesn't exist, it's probably merged in). Any bugs you find, feel free to report them on github on the official issues page, or in the google groups.

There are some issues when you move from one computer to another, so I put the curses exe, and an egg (for pycharm debugging) in the root of the flash drive. Then, I created a batch file that was just these contents:
"%~dp0\Portable Python\App\python.exe" -U setuptools
"%~dp0\Portable Python\App\Scripts\easy_install.exe" pip
"%~dp0\Portable Python\App\Scripts\pip.exe" install virtualenv Pygments pyserial requests requests-oauth --upgrade
"%~dp0\Portable Python\App\Scripts\easy_install.exe" curses-2.2.win32-py2.7.exe
"%~dp0\Portable Python\App\Scripts\easy_install.exe" pycharm-debug.egg

That fixed any issues I had when moving to another computer. The last line is optional and only needed if you're using pycharm's debugging like I am. I will probably do another blog post on how to set up that, because it was definitely interesting to do.

EDIT: Also, not all bugs have been fixed and pushed to the 0.5X-dev branch. I'll update this again when it's ready.

Tuesday, January 7, 2014

A day with Google Chromecast

Today I decided to buy a Google Chromecast. This nice little device plugs into the HDMI port of your TV, and gets its power from either the USB port of your TV (Warning, plugging it into the service port might be dangerous for reasons unknown to me) or from a little wall adapter.


Setup was a little difficult at first, but most things are difficult when you swap two digits in your password. When you first load the device up, it will tell you to go to a URL. I went there on my Galaxy S3, and was greeted with an app link. Once I downloaded the app, it discovered a device was on the network I was on. How did it do this? I'm not actually sure. It didn't know any of the networks authentication at this point, so I'm guessing there's something low level with mac addresses that allows that to work.

After clicking on the device, it puts a code on the TV and one on your device just to make sure you're talking to the right device. It will then ask you what network you want to connect to, and it's credentials. After entering those, you're all set up to go. It was actually fairly easy.

My favorite part of setup was that the android app switched my wifi network from my home wifi to the chromecast acting as an access point for setup until it itself could connect to the home network.


Operating the device could hardly be more intuitive. Clicking the icon on any supported app allows you to transfer the content to that device. I watched a few netflix shows, and it worked well. My only complaint, which is probably more or less unavoidable, is that there is a good lag between doing something like changing volume, or pressing pause and the chromecast actually responding to your request.

Something else that I disliked was how content wouldn't always save its position. If I want to pause a youtube video, switch to streaming a tab, and then go back to the youtube video, the video had to start over. Obviously that's just an issue with the youtube app not saving the position.

How It Works

So how does this magical device work? Well, there's two parts to this: a sender and receiver. The receiver is literally just a webpage with some javascript to handle the API. The sender is the app that handles the content for the receiver. So, if your receiver has a place for a video, your sender tells it what video to play. Fairly easy and intuitive to actually run with. The sender just tells the device its app id, and the chromecast loads your receiver.


Currently, development is very limited. They are in the beta stages of development, and you can't develop for a device unless it's been whitelisted. I'm still waiting on my device to be whitelisted for development.


One security concern I have is that any device on the network can access your chromecast if they want to. I would love it if the chromecast had a password to be able to access it, but would then whitelist those devices' mac address or some uuid for the device. Either way, I'd like it to be a little more secure on public networks.


Overall, I like the device. Should you go out right now and buy one? Probably. I feel like this technology should be worth more than $35, and the price might go up once people get their hands on the official SDK.

Tuesday, February 12, 2013

Forcing Serial device to use the same Serial port

EDIT: Note, that this caused an error that I'm currently trying to work out. I'll remove this once I've figured it out. Basically, it doesn't treat the second device as a serial port.

Note, that I'm currently writing this to use on my Raspberry Pi to make it work better with BotQueue's client software, bumblebee. When you unplug a usb serial device, and plug it back in, the serial port changes.  So, if you have it as /dev/ttyACM0, unplug it and plug it back in, you'll see it's now at /dev/ttyACM1.

Throughout this tutorial, I'm going to use /dev/ttyACM0 since that's the current port of the device I'm trying to get to stay.  Note, that this is a device rename, not a symlink. I'll be using /dev/ttyJasmine for the new port since Jasmine is the name of my printer.

First up, let's find some info about the device:
udevadm info -q property -p $(udevadm info -q path -n /dev/ttyACM0)
It should spit out some info. The line that we need to pay attention to is ID_SERIAL_SHORT.

So in the case of my arduino, (excluding all irrelevant fields):
ID_SERIAL_SHORT=<removed for the blog post>
Now it's time to set up what's called a udev rule.  Run the following command, replacing nano with your editor of choice: (Note, that I chose 45 arbitrarily. Just for fun, you might want to research how the numbering system works)
sudo nano /etc/udev/rules.d/45-serial-devices.rules
Go ahead, and add the following line, replacing the items in < > their appropriate values.  So in my case, I'd replace <SUBSYSTEM> with tty and <ID_SERIAL_SHORT> with the serial device I found earlier. (Note, that this is all one line)
SUBSYSTEMS=="usb", ATTR{serial}=="<ID_SERIAL_SHORT>", NAME="ttyJasmine", GROUP="dialout", MODE="777"
Go ahead and save the file. After a fresh reboot, you should see your device have the name that you assigned to it.  If not, then run the following command to see what the problem might be:
cat /var/log/daemon.log | grep udev
Remember to change your config.json to use the new port if you did this for botqueue.

Saturday, February 2, 2013

Run Bumblebee on Raspberry Pi boot

In my last post, I showed you how to set up a raspberry pi with BotQueue. This time, I want to show you how to start it on boot.

First, let's create an executable script to run bumblebee with a single command. I'm doing this so that if I ever change the directory BotQueue is in, I only have to change one file. So to edit the new executable, run the following command (replacing nano with your text editor of choice. I use vim personally):
sudo nano /usr/bin/bumblebee
You should be presented with a blank file. Add the following lines to it, before saving and exiting (replacing /home/pi/BotQueue/bumblebee/ with wherever you put bumblebee. Note that you should not use ~, but instead /home/pi/):
cd /home/pi/BotQueue/bumblebee/
After that's saved, you need to allow people to execute it. Type this to get the desired effect:
sudo chmod a+x /usr/bin/bumblebee 
Of course, you should run "bumblebee" now to see if it worked. Next up, we need to make the user automatically login on tty1. Again, I'm assuming you are using the pi user here. If you aren't then just change the username in the instructions accordingly. First, edit the /etc/inittab file. You'll need sudo permissions, of course:
sudo nano /etc/inittab
Find the line that looks like this:
1:2345:respawn:/sbin/getty 38400 tty1
Change it to this:
#1:2345:respawn:/sbin/getty 38400 tty1
And add this below that line (replacing pi with the username you want logged in and running bumblebee with):
1:2345:respawn:/bin/login -f pi tty1 </dev/tty1 >/dev/tty1 2>&1
 Good good. Now, in the home directory of the user you did that too (in most cases, that'll be your own), edit the ".profile" file. (notice the '.' at the beginning of profile):
nano .profile
At the bottom, add the following lines (If you don't care about the terminal screen going blank, leave out the setterm line):
if [ $(tty) = /dev/tty1 ]; then
    setterm -blank 0
    sleep 10
And now, just run this command to reboot:
sudo reboot
There you go. Once you have gone through a reboot, the program should be running in the main terminal window, while still giving you the ability to ssh in. The only problem with this is that you can't type things like q to quit the program. This is a problem with bumblebee, which I'm hoping to eventually fix. Although, I wrote this tutorial and the last one all over ssh, so it's completely possible to not need a keyboard on the host computer.

Monday, January 28, 2013

Raspberrry pi reprap controller with BotQueue

I've recently been interested in making my 3d printer more compact. But first, a small introduction to my printer.  My printer is a reprap prusa mendel based printer. It uses a RAMPS 1.4 board and a budaschnozzle extruder. Her name is Jasmine, which stands for "Just Another Sexy Machine, Is Notably Expensive" at the suggestion of a friend.

So, now that that's over, let's get started.  For this, I bought a PNY premium 8GB SD card for $10.  Make sure it's more than 2Gb. I did 8 just to be more on the safe side. I've installed images directly to the card before, but I wanted to try the Raspbian Installer to see how well it worked. I tried it, and it didn't install everything I wanted. Or I should say this system is probably more designed to be run as root and I didn't want that. So, download Raspbian "Wheezy" from here. Install it to the sd card using some method described on this page. It shouldn't be too painful to install.

Now then, time to install our software. Head on over to BotQueue and sign up for an account. After logging in, you'll be able to create a new account. Log in to your raspberry pi (over ssh is fine).

You'll have to log back in for the group change to take effect, assuming you had to install sudo in the first place.
sudo usermod -a -G dialout pi
sudo apt-get install git-core python-pip
sudo pip install pyserial
(If anyone can figure out how to get pyserial with this release easier than installing pip, I'd be somewhat grateful)
This will install the main core of git so we can download the repo. Now, there is the repo currently supported by Zach Hoeken here. There is also my version here. Mine fixes some problems like flickering with the raspberry pi, but you should probably use Zach's version for now. Run the first one for Zach's or the second one for mine.
git clone
git clone
Excellent! Now run these commands:
cd BotQueue/bumblebee
It will give you a link (or open up a web browser). If it opens up a web browser, login through that window or just close it to see the link printed on the console.  This is probably a great time if you're doing this over ssh, because you can just copy and paste the link in your browser. Technically, you could have done this from the built in browser, but I didn't want to do this from a raspi. It may ask you to login. It will then give you a pin number to authorize the app with. Type the pin number on the raspberry pi.  After it authorizes, you'll be brought up to the main menu. Press q to quit.  Now go here, and follow ONLY step 4. This will add your bot to the config.json file. In the future, I'm planning to make this more automated. I'm not sure if Zach is thinking the same.

Note: You might be able to only run your bot at 115200 baud. I'm currently working on that. I think you have to overclock the pi to be able to do more than that.  I'll look into it and report back.

After that's all saved, just to make sure, restart the raspberry pi:
sudo reboot
Then, just restart the client software by running:
Now, go back to, and click on "Actions" and then "Register Bot". Fill out all of that information, but be careful. The name of the bot here must match verbatim to the bot listed in your config.json file. If not, then the server won't send requests to the correct bot.

So, you should have the client software running and connected to the server. If you upload a .gcode file to the default queue, your bot should grab it and start printing. If not, check to make sure that the bot is online and idle. The program should list your bot's id, it's name, and it's status should be idle. Send it a .gcode file and let it print!

 Note: This tutorial does not cover some important security types like not permitting root login via ssh. That one can be found here.

Also note, that I am human, so there is most likely a mistake somewhere in this document. Next blog post: how to make it start up as the main tty on boot.