New Sony LANC Remote Commander

                 
            Applied Logic LANC Controller                                                         Applied Logic Remote Commander

Applied Logic has just released a new embedded controller product — the Applied Logic Remote Commander.  Typically, our LANC Controller is connected to a PC and controlled by our LANC software package.  The Remote Controller can replace the PC/software — when these two boards are connected together via a serial cable, the Remote Commander can deliver commands to the LANC Controller to remotely control the camera’s functionality. 

Commands are sent by pressing buttons on the Remote Commander.  We pre-program this board with the following commands:

        * Zoom out, Zoom In, Focus Auto/Man, Focus In, Focus Out, Photo Capture
        * Stop, Rewind, FF, Play, Pause, Power Up

There are an additional 6 buttons that can be programmed for any other Sony LANC command.

Check it out at www.appliedlogiceng.com

Another ROV project

             

We’ve been working with Patricia Terry, a ROV Technician with the Pacific States Marine Fisheries Commission/Department of Fish and Game on modifications to their underwater ROV — similar to the project we helped NOAA with, the PSMFC is modifying their ROV to include a Sony Handycam HDR-XR500V camcoder on board the ROV.  They are using our LANC controller board and associated software to control the operation of their camera via their topside operations.  They want to use this setup to capture still photos while the ROV is operating underwater.

Our technology is a perfect fit for this application — with our LANC Controller, we can control all camera and recorder functions remotely, either via our controller software that runs on a PC or via our new ALE706 remote commander, which sends commands  to our LANC controller by the press of a button.

New patent issued

patent

I’m happy to announce that I’ve received notice that my fifth U.S. Patent has just been issued.  It is U.S. Patent Number 7,620,815 and is entitledCredential production using a secured consumable supply”.

This patent is based on some work I did back at Fargo Electronics (which was acquired by HID Global) — Fargo was a designer and developer of plastic ID card printers and we had a need to securely control how particular cards were to be issued at the end user’s location.  We used an RFID tag on the printable ribbon substrate that could be encoded during the production process with a unique ID code. This digital code would then be read by the end user’s printer when the ribbon was inserted into the printer.  The code on the ribbon cartridge would then need to match the same code that had been installed in the printer before the printing process would be enabled.

I’m proud to be part of the team that developed this technology for Fargo.

New Article – Avoiding Bad Embedded System Designs

I’ve written a new article that has been posted on the Applied Logic web site.

Being involved in embedded system design for over 28 years, I’ve seen some common errors that inexperienced designers and developers frequently make when implementing their product designs.  I’ve captured seven problems that seem to occur the most frequently.  Give it a read and see if you agree.

The article can be found here — http://www.appliedlogiceng.com/index_files/Page1094.htm

Agile software development in a staged gate environment

While I’ve never been considered an Agile zealot (and I know a few), I do agree with the basic tenets of Agile software development.  When I was first involved in developing software more than 25 years ago, the Waterfall (WF) Method was pretty much the only game in town.  The WF Method requires that all requirements be defined prior to doing design, then the design must be completed before development can begin, development must complete before testing can begin, and so on to the end of the project.  In hindsight, pretty much a horrible way to develop software effectively.

The advent of Agile methodologies stressed four basic ideas:

1) Individuals and interactions over processes and tools.
2)
Working software over comprehensive documentation.
3)
Customer collaboration over contract negotiation.
4)
Responding to change over following a plan.

It’s outside the scope of this blog to go into the details of an Agile project, but if you’ve done software development, you can probably appreciate the fact that these principles lead to more effective results as compared to Waterfall development.

In the last two organizations I’ve worked in, large multi-faceted projects that include hardware development, product marketing, manufacturing, as well as software development are typically managed using a Stage Gate (SG) process, which shares many similar characteristics to the old Waterfall process — first, the project is scoped, then a business case is built, then development ensues, then testing, followed by deployment.  Each stage ends with a “gate” review, where the deliverables from the stage are reviewed and approved.

So the dilemma is this — how does the software development team conduct their development using Agile practice while conforming to the larger SG process being used to manage the overall project?

The answer is in properly integrating Agile practice in context with the various stages of the Stage Gate process.  I have been successful in implementing such a practice with software teams working inside of larger cross functional projects and have had great success in delivering software products in this complex environment.

If your team is facing this challenge, give us a call at Applied Logic.  We’d be happy to show you how our methods can work for you and deliver results within your Stage Gate environment.