imagitronics.org

I have created a functional base64 encoding method for the ybox.

It’s not ideal as it requires the programmer to declare an output array large enough to hold the result of the encoding procedure. I tried everything I could think of to avoid this by using the size of the input string (strsize(in_ptr)*(4/3)) to store the output, but I couldn’t get it.

Download the updated base64.spin.

Sample usage:

 
CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

OBJ
  text : “TV_Text”
  b64  : “base64″

VAR
   byte outstring[25]

PUB start | i
  text.start(12)

  b64.encode(string(”admin:admin”), @outstring)
  text.str(@outstring)
  text.out(13)

  b64.encode(string(”admin:password”), @outstring)
  text.str(@outstring)
  text.out(13)

  b64.encode(string(”Die SPIN Die!”), @outstring)
  text.str(@outstring)
  text.out(13)

  b64.encode(string(”meh”), @outstring)
  text.str(@outstring)

  repeat
 

And a sample image from the above code:

If anyone has any tips that can help get rid of the need to declare the output variable’s size, please let me know. Tim

Well, it’s not very interesting (yet?) but I started working on a uTorrent download monitor using the ybox2. At the moment, it’s really nothing more than a simple hack. The ybox2 is running a slightly modified infowidget. When I say slightly modified, I mean I added one line to insert a Basic base64 authentication header for the uTorrent webserver:

tel.txmimeheader(string(”User-Agent”),string(”PropTCP”)) tel.txmimeheader(string(”Connection”),string(”close”)) tel.txmimeheader(string(”Authorization”),string(”Basic YWRtaW46YWRtaW4=”)) tel.str(@CR_LF)

I haven’t figured out how to write my own base64 encoding routine in Spin yet, so for the time being, I used python to generate the base64 encoding of the default username/password for the uTorrent web server (admin:admin).

Apart from that, I’m using a uTorrent python library on the web server to generate a properly formatted document for the infowidget and the file is updated every minute by the Windows Task Scheduler: The simple python script can be found at http://pastebin.com/f2a47b927. 

TODO:

• There’s a lot that I’d like to do, but I’m currently in the midst of a hate/hate relationship with Spin.
• Ideally, I’d like to create a base64 encoder routine, and create a set of routines in Spin that can query the uTorrent webui natively without the python proxy.
• If/when that happens, I’d like to add remote control, scrolling, and the ability to select a download to view details. We’ll see how my relationship with Spin evolves. I’m not exactly a good programmer to begin with, and Spin is shaking me up pretty good.

The spin language used by the Parallax Propeller chip is pretty brutal. There are quite a few little nuances that go against everything you’ve ever learned in your intro to programming courses. I felt kind of like a hacker in the mid 80’s when I got overly excited to see a simple “Hello World” type application on the screen.

It’s really not the language or the chip that’s difficult, per say, but rather the ybox2 specific libraries that implement the TCP/IP stack. A lot of the code is left up to your application, so even the simplest of the network-enabled widgets work out to around 300 lines of code. That’s a lot to digest when you’re just learning a new architecture and language.

Not to mention I’ve been pretty spoiled by Visual Studio and Eclipse for the past 4-5 years. I’m so used to having all the documentation described to me as I type, that having to find the source files and check what methods/constants/variables are available is a real drag!

My wife bought me a ybox2 for Christmas and I just got around to assembling it this weekend. The ybox is a pretty amazing little ethernet enabled set-top box gadget that gives you the ability to create your own widgets which can be displayed on your TV. I have a couple of widgets in mind that I’d like to create, but the ybox uses a proprietary Parallax Propeller chip, which requires you write code in either Spin (which looks like Pascal threw up on win32 asm) or straight assembly code. Oh joy…

I just realized that the latest Wordpress update had messed up the embedded video on the Bongopong page. I fixed it, so you can laugh along with me (at me).

On a side note, the biggest thing I heard about that project was that it looked too hard. Rest assured that it was difficult because I was using a DIY Bongoboard and the skateboard deck has a concave bottom - coupled, of course with my complete lack of coordination and balance.

My wife got me a real Bongoboard for Christmas this year, and it’s 100 times easier to use. I may have to bring this one back. With a left/right moving game like breakout and a stable board, I think this could be a lot of fun.

I just finished my latest hack. I modified a ThinkGeek R/C Moon Phase light so that it reflects the current lunar phase in realtime.

Essentially, the R/C Moon Phase light is a nightlight that comes bundled with an infrared remote control. The controller allows the user to change the moon’s current phase with the press of a button - or automatically cycle through the standard phases of the moon throughout the day.

I decided that it would be more interesting if the model moon actually reflected the current phase of the moon based on the date. I did this by replacing the original PCB with an arduino and aDS1307 realtime clock module from Sparkfun. The DS1307 module maintains the proper time and date, while the arduino calculates the current phase of the moon based on the date. The RTC module contains a coin cell battery backup that enables the internal clock to maintain the proper time, even without power, for up to 17 years!

I also included a simple C# application for Windows.NET that updates the DS1307 in case it starts to drift over time.

Check it out at www.imagitronics.org/rc-moon/

• Python
  Some very nice python routines that read NMEA GPS strings and transmit them over UDP.
  (tags: python gps)

I had a chance to sit down a play around with the Maxbotics LV-EZ3 ultrasonic range finder. The EZ3 is a low cost, reasonably high quality range finder capable of measuring distances from around 6″ all the way up to 254″. The device is fairly straightforward and can output analog voltage, PWM, or serial data (although strangely, RS-232 not TTL). The analog output is the obvious choice, as I will be using my arduino board to interact with the device.

When I initially connected the device I was mildly discouraged. The values returned on the analog pin seemed slightly erratic. Too much so to even process a data sample. The MaxSonar-EZ1 FAQ recommended implementing a low pass RC filter using a .1uF capacitor and 1k resistor, which stabilized the output nicely.

The next step was to convert the data into inches so that it will be more useful to Terry. Analog voltages on the arduino range between 0 and 1023 and are scaled based on the analog reference input. The default analog reference is 5V. This means that 5V applied to the arduino’s analog input pin is interpretted by the arduino as 1023. The arduino also has the ability to use an internal analog reference of 1.1V on the ATMega168 microcontroller (2.56V on ATMega8) or an external reference that can be specified by applying voltage to the arduino’s AREF pin. Information on the arduino analog reference configuration can be found here. The Maxbotics EZ3 outputs a maximum of 5V, therefore I was able to use the default reference.

With the low pass filter functioning properly and the analog reference properly set, I was ready to convert the output into inches. The arduino analogRead reference page indicates that each unit (0-1023) represents 0.0049V, and the Maxbotics LV-EZ3 datasheet specifies that an inch is represented by 9.8mV (0.0098V). From there it was simple to translate the arduino’s analog input into inches: ((units * 0.0049)/0.0098).

The code seems to work flawlessly. The data doesn’t seem to vary beyond an inch in either direction even without data sampling and when the unit is jostled around. I will, however, likely sample the data using a mode average that will return the most frequently occurring value in a given dataset. Tomorrow I will try to uncover an effecient algorithm for this, even though it’s completely usable as-is.

These little wall racers look like an incredibly fun side project to pass some time when not working on the autonomous vehicle project.

Fritsl, from letsmakerobots.com retrofitted these little RC cars with some artificial intelligence that allows them to race around any room in your home. The cars are designed to ride counter-clockwise along the wall simulating a standard oval track.

I would really love to make a half-dozen of these things with various levels of AI aggression and watch them battle it out around the house. You can peep the video of the little fellas in action at letsmakerobots.com

We’ll put this one into the “Why didn’t I think of that?” column. The good folks on the RepRap project have made available a very nice looking Arduino Breakout Shield that brings the Arduino’s I/O pins out to screw terminals providing for a semi-permanent way to connect your Arduino board without soldering. As of this writing they still have 41 kits in stock… minus the two that I just bought.

Having spent last weekend being too stubborn to deface my beautiful Arduino board by removing the headers, and opting instead to spend my entire Saturday rigging up a very sad electrical-tape-wiring-harness-thingy, I’m really excited that Make: Magazine stumbled across this.