After quite some time without development activity on VoIP32, I began investigating modifying Retro BSD to run on it.  Retro BSD is a port of 2.11BSD Unix to the PIC32.  It operates by loading the Unix kernel and hardware drivers into the PIC32′s Flash memory, then loading individual executable files from an SD card and executing them from RAM.  Of particular note, the project includes a BASIC compiler and a MIPS assembler and linker in the default filesystem image, so development for the system can happen on the system itself.   While the source for a C compiler is included, it is too large to run from RAM and is currently not operational.  Still, to say that the Retro BSD project is impressive is an understatement.

Due to the hard work of Serge Vakulenko, who started the PIC32 Unix effort, modifying the project to run on new hardware is as simple as editing a couple of Makefiles.  After doing so, using MPLAB to download the kernel to VoIP32 was pretty straightforward.

The project includes drivers for an SD card connected via SPI, and supports the use of serial or USB for the console connection.  Over the weekend, I was able to modify my existing HD44780 LCD driver and graft it onto the Retro BSD kernel.  The LCD appears as ‘/dev/lcd’ in the Unix filesystem, and writing to it is as simple as piping text to that file.   As time allows, I would like to add simple networking functionality using the board’s onboard PHY.

Retro BSD is an extremely impressive project, and I think having a real operating system like Unix running on our hardware has the potential to greatly increase its value.  We’ll be sure to write more about future successes with this software.  It’s awesome!

As you may know, one of the projects in the pipeline here at NBitWonder is a software-defined radio receiver, loosely modeled after Jeri Ellsworth’s receiver published earlier this year.  As of this past weekend, NBW-SDR (as we call the project) is operational!

The video features a live reception of WWV, one of the United States’ atomic clock stations (much more information here).  The station is located near Fort Collins, Colorado, some 2000 miles from the receiver’s location in Virginia.

There is much more work to be done on the software, as you can tell from watching the video.  For instance, only AM reception is implemented right now.  The signal processing functions still need some work, and more appropriate gains should be chosen for the entire signal chain.  Still, it is rewarding and reassuring to see the project working at some level.

Be sure to watch the github repository and the forum for much more information as project development proceeds.

Introduction:

Dangerous Prototypes is a fantastic open hardware community that we at NBitWonder follow closely. One of the most unique, compelling features of Dangerous Prototypes is their free PCB giveaways. They produce a large number of PCBs for their prototypes, and give away the leftovers for people to try building their own versions of the Dangerous Prototypes projects. Some of these are through weekly events, some are to incentivize people to do things for the site (such as coming up with T-shirt designs, etc.), and still others are offered to “dedicated developers”.

I was curious exactly how Dangerous Prototypes determined what a “dedicated developer” was, so I sent them an email (some time ago, now) asking how they implemented this.

The Bus Pirate:

As a result of that email, the nice folks at Dangerous Prototypes sent me a free PCB code to try building my own project. I opted for the Bus Pirate project, as it’s an extremely useful tool that I could get a lot of mileage out of prototyping and developing NBitWonder projects. For those unfamiliar with the Bus Pirate, think of it as a logic emulator — a device that can pretend to be one side of a given interface (USB, I2C, etc. etc.). (continue reading…)

Introduction:

Over the course of the past year, NBitWonder has been undergoing an effort to improve the way in which we document and share projects.

It started almost a year ago with our initial documentation post. From there, we moved forward, releasing a set of Open Documentation templates, written in LaTeX, and available in our github repository. Those were used for quite some time, and provided a nice, standardized layout for all NBitWonder projects.

Further Refinements:

As nice as writing project documentation in LaTeX is, however, it suffers from a steep learning curve, and can be quite challenge to coerce into providing a particular desired output. Writing project documentation in LaTeX is somewhat akin to writing a dynamic website in notepad; it can be done, but arguably better (or at least more productive) methods exist for creating the desired end product.

With that in mind, we set out searching for a more powerful software package to write documentation in. The stipulations were that the software had to be open source (free as in speech and free as in beer), cross-platform, and easy to use, allowing many end users to adopt our work in their own hobbyist projects and allowing our work to be easily accessible for everyone. After review of the narrow list of softwares available that met these requirements, we settled on OpenOffice.org. The NBitWonder open documentation system, written in OpenOffice.org (OOo) is available here, and all existing NBitWonder projects at the time of this writing have been converted to use this new OpenOffice documentation.

OpenOffice: Pros and Cons

There are a number of advantages to using OpenOffice, as detailed below:

• Powerful User Interface:OpenOffice is an office suite, rather than a typesetting program. As such, it has a vastly more intuitive graphical user interface than LaTeX, and documentation output can be seen live without requiring compilation.
• Extension Support:As of version 3.0, OpenOffice.org supports the writing and development of extensions and macros written in a number of programming languages (python 2.6.1, in particular). As such, documentation improvements for the Open Documentation system can be developed and distributed in the form of OpenOffice extensions. This is a marked improvement over LaTeX, which doesn’t (in our experience with it) provide a particularly interface for user macros, as well as a considerable improvement over packages such as Microsoft Office, in which macros are only supported in various flavors of Basic.
• Open Source and Cross-Platform:OpenOffice is well known and truly cross-platform, including a Linux version, which is less than can be said for Microsoft Office or many other open source office programs.

Of course, with all of these advantages, there are a handful of disadvantages as well:

• Support for Developers: OpenOffice started out as the proprietary software package StarOffice, which was then purchased by Sun Microsystems in 1999. Sun Microsystems was later acquired by Oracle. Recently, however, Oracle parted ways with OpenOffice, setting it adrift without major corporate support for the system or funding for the top level developers. In spite of this, the OpenOffice project has been picked up by the Apache Foundation and is currently being hosted and supported there, and future stability of the project remains strong.
• Advanced Typesetting Capabilities: When it comes to formatting sophisticated mathematical equations in beautiful textbook style, LaTeX is the unquestioned king. Support for formulas in OpenOffice is there, though not nearly as good as LaTeX-based documentation. This is a secondary concern, however, and it is our belief that the advantages of OpenOffice over LaTeX outweigh this small disadvantage.

More work on NBitWonder’s documentation and software tools will be made available soon, but for the time being, feel free to try out our latest efforts by grabbing the Open Documentation System from our github repository.

I took a couple of hours tonight to put together the Software Defined Radio PCB, as the parts arrived a couple of nights ago.  Software development has already started — check out the git repository for the progress so far.  Be sure to watch the project in the forum to stay abreast of project progress!

Introduction:

Ah, Halloween. Next to Ramahanaquwanzmas, one’s birthday, and a handful of other possible days, is there a better day of the year? Not only is it socially acceptable in this small time window to walk around in public dressed up as a robot, vampire, etc., but if you’re maker-savvy you get to build something fun! I enjoy Halloween a great deal, and have gone to some pretty impressive lengths in years past to get a kick out of the holiday, and this year would be no exception!

I’ve always had a thing for Iron Man. He’s often hailed as the engineering superhero, and any super hero that can be seen on the big screen holding a soldering iron is grade-A material in my book. With this in mind, I set out to build an arc reactor, like the one seen in Iron Man.
(continue reading…)

The latest revision of our Software Defined Radio project PCBs arrived the other day.  While we wait for parts to arrive, be sure to check out the progress over in the forum!

This is the 14th post in a series detailing my efforts to construct a RepRap Mendel, an open source 3D printer.

Introduction:

The RepRap Mendel is a complex machine, that is quite challenging to build and calibrate. However, there’s nothing quite like the finished product, and the satisfaction of having completed one of the early generation rapid-prototyping devices makes the challenge and effort worthwhile. In total, the RepRap Mendel Build took 3 months and 14 blog posts, which are listed below for completeness:

1. Part 1: Prologue
2. Part 2: Awwww Nuts
3. Part 3: XYZ
4. Part 4: Toil and Trouble
5. Part 5: Extrudapalooza
6. Part 6: Electronics Testing
7. Part 7: I Love it When A Build Comes Together
8. Part 8: Calibration
9. Part 9: Fix It!
10. Part 10: Calibration (Part 2)
11. Part 11: Build Platform Blues
12. Part 12: Fix It! (Redux)
13. Part 13: Victory!
14. Part 14: Lessons Learned

(continue reading…)

This is the 13th post in a series detailing my efforts to construct a RepRap Mendel, an open source 3D printer. For the rest of the build series, see here.

Introduction:

Previously, I built the printer, broke the hotend (twice), tore this thing apart and retooled it a half dozen times. It was not clear if this build would ever be done. Still, the hotend was working, electronics were working, everything except the printbed was working, and I seemed closer to victory than ever before…

Heated Printbed 2: Electric Boogaloo:

The problem with the printer was fairly simple: everything worked, but the plastic would not stick to the printbed. Originally, I used an aluminum printbed covered in Kapton tape with power resistors mounted to the bottom, a heated printbed. However, when testing the original heated printbed, one of the power resistors began to boil and give off smoke, prompting me to switch to an MDF bed covered in blue painter’s tape. Further discussion and analysis revealed I had inadvertently wired one of the power resistors in parallel with the other 3 in series when I constructed the original hated heated printbed. Oops…
(continue reading…)

This is the 12th post in a series detailing my efforts to construct a RepRap Mendel, an open source 3D printer. For the rest of the build series, see here.

Introduction:

Last time, the RepRap Mendel was nearly working, with the exception that plastic was not sticking to the build platform. After attempting a variety of build platform materials and options, an astute IRC channel member noted that the heater block on my hotend was screwed all the way up the nozzle threading. As such, the plastic had a couple of centimeters and seconds to cool before reaching the printbed. In order for 3D printing to be done successfully, this issue was going to have to be resolved.

Not Again!

Last time I broke the hotend on my printer, I redesigned a bracket plate for the printer that improved the hotend mounting for my extruder considerably. As such, the hotend was considerably easier to remove this time around, and even didn’t require me to completely disassemble the X-carriage this time. Unfortunately, due to thermal expansion or a number of other possible explanations, the block was secured to the threads of the nozzle and would not budge. In attempting to unscrew the heater block, I broke one of the leads off the power resistor. Craaaaaaaap.
(continue reading…)