Wednesday, December 30, 2015

New Year Revival 2016

Apologies to anyone that has been following this blog for the past couple years. I have been distracted by other unrelated tasks/projects. I am hoping to revive this blog with more boat electronic related projects this year.

Topics to include:

  • Sailboat distributed power
  • Amateur radio digital communications
  • Other gadgets

Happy New Year 2016!

Monday, December 31, 2012

Christmas Pi

Just in time for Christmas (actually, one day late) I received the two Raspberry Pi's that I had ordered three or four weeks ago from Allied Electronics. What is a Raspberry Pi? Well, similar to the BeagleBoard, it is an ARM based single board computer that runs the Linux operating system. It measures 2.5 x 3.5 inches. It differs from the BeagleBoard with less computing power and fewer hardware features to help keep the cost low. Only $35 for the Model B!

The Pi is in high demand and retailers are not promising delivery dates as production tries to keep up with demand. Coincidentally, Santa brought me some nice RPi accessories (tiny wireless keyboard, wifi adapter, case), so I have been busy the last few days getting it all together.

So far I have downloaded and installed the "soft float" version of the Debian "Wheezy" Linux distribution. Soft float will be necessary to run Java on this processor, which I intend to do.
Bottom to top: RaspberryPi, BeagleBoard, RaspberryPi with case
One of the first experiments will be interfacing the Raspberry Pi and Arduino which I hope generates some application ideas.

Saturday, December 29, 2012

Radio Controller Development Environment

Here is a block diagram of hardware and connections being used to develop and test my little radio controller "magic box".
Hardware devices and connections
The PC, running the dev tools and terminal program is used to upload and download freshly compiled firmware to the Arduino UNO. This is uses the one and only hardware serial port on the UNO.

An RS-232 serial connection connects the ICOM CT-17 box, TenTec RX320 and Kenwood TM-D700A to the Arduino. These are connected using the "SoftwareSerial" UNO driver which allows any two available digital pins to work as an RS-232 serial port. Using SoftwareSerial is ok for sending data OUT to the radio, but there seems to be issues when reading data IN, like when detecting a response to a command.

Tuesday, December 25, 2012

Icom Receivers, Transceivers and the CI-V Interface

The next set of radios targeted for remote control is a couple ICOM units. I have an IC-706MKIIG multiband amateur rig, and an IC-R10 handheld general coverage receiver.
ICOM IC-706MkIIG transceiver, IC-R10 receiver, CT-17 CI-V interface

Compared to the TenTec radio, the ICOMs have a more sophisticated serial interface. ICOM designed a fairly compact, yet robust, protocol for serial communication. Control of ICOM radios is done via their "CI-V" interface, which has been around for over ten years, and is still supported in their newer radios.

The CI-V interface takes a three-wire RS-232C serial connection  (RX/TX/GND) and converts it to a two wire TTL level serial serial connection. The data protocol is variable sized "packets" that have byte constants marking the start (0xFE 0xFE) and end (0xFD) of the packets. The radios also have standardized response packets for indicating success, failure, and returning data for any packets sent to the units. Some CI-V interfaces, like the CT-17 shown in the picture, can control multiple radios via one serial port. Each radio has it's own identifier, which is included in the CI-V data packets. The CT-17 routes messages to the appropriate radio based on this identifer.

The Arduino drivers are written in C/C++ using Atmel AVRStudio,  extending the infrastructure established for the TenTx RX320 interface. This will allow common functions between radios to be accessed  in a uniform fashion, while having the ability to expose additional functionality provided by the ICOM units.

Where the TenTec radio had more "human readable" ascii commands, the CI-V interfaces deals with bytes. Therefore, a little more bit twiddling must be done when programming the Arduino. The C/C++ language makes this real easy, though it has been a while since I have programmed on this level. A constant challenge when writing these drivers, is that the Arduino UNO has limited firmware memory. So careful thought must be given when designing code to make it as small as possible, something I have not done since my DOS TSR (terminate and stay resident) application days years ago.

Commands for the ICOM radios implemented so far:
  • memory/vfo mode
  • set dial frequency
  • select vfo a or b
  • select memory x
  • select radio mode (AM, USB, LSB, RTTY, FM, WFM)
I will be posting more info about the Arduino command structure used to drive the radios as code becomes firmed up.

Tuesday, December 18, 2012

Remote Controlled Device: Shortwave Receiver

One of my goals for these "boat electronic" projects, is to arrive at a system that will enable wireless remote control of various devices using some human interface device "du jour". Today, that would likely be a smartphone or tablet running Android or iOS. Imagine plugging in a "dongle" into a device, then "automagically" connecting and controlling the radio via your smartphone or tablet, over WiFi.

It is this "WiFi" dongle that I am designing.

I have a number of "legacy" devices lying around that I wish to use. Today, I am talking about my Ten-Tec RX320 general coverage radio receiver. It is over ten years old now, but was quite the thing in its day. This radio is one of the first "software defined" radios, in that it is, quite literally, a "black box" radio. No knobs, switches or displays for which to interact. Control of the device is solely by an external connection (usually a computer running some "radio" software) via serial port.
The blank front panel of the RX320. Blank and black!
The RX320 command set is fairly simple, which makes it an ideal device to begin this project. But I also have a couple other radios, each with different command sets and capabilities. Another design goal is to abstract the "interface" between the controllers (smartphone, tablet, etc) and the radios. That is, I want to send a statement to each radio such as "TUNE to frequency F" and have them understand "what" to do, even though each radio differs as to "how" it is tuned. Ideally, all of this abstraction will happen on the "dongle", as close to the radio as possible.
Rear connections: power, serial, speaker, antenna. Thats it!!
The dongle will be an Arduino UNO, with a software serial port connected to the RX320. The Arduino will receive general commands from an external source (WiFi, eventually), and translate them into RX320 specific commands to achieve the desired behavior.

Sending commands and getting responses from the radio

I now have all of the commands "native" to the RX320 coded into the Arduino and tested. Native commands include

  • set speaker volume
  • set line out volume
  • set AGC (automatic gain control)
  • set bandwidth filter
  • set mode (AM, USB, LSB, CW)
  • set oscillator parameters (used to tune a specific frequency)
I also have an initial set of high level abstracted commands.
  • ON - turn radio on
  • OFF - turn radio off
  • DIAL - set the dial frequency (in hertz)
Arduino controlling the RX320

One nice thing about using an Arduino for this project, is that the UNO can be programmed to augment features of the RX320 that were not provided by the radio's manufacturer. Possibilities include:
  • station memory/presets
  • frequency scanning functions
Command definitions will be refined over time.

The next step is connecting the Arduino to the ethernet network to enable control by remote hosts (computers, smartphones, etc).

Sunday, December 16, 2012

BeagleBoard xM in the Lab

Yesterday, I received a BeagleBoard xM in the mail.
Beagleboard xM connected and running
The BeagleBoard xM is an inexpensive fully functional solid state computer on small 3 inch square circuit board. Powered by 5 volts it has the ability to run various open source operating systems (Linux being the most common). Some hardware features are:

  • four USB ports
  • ethernet port
  • HDMI out (for monitor)
  • S-video out (for monitor)
  • audio in
  • audio out
  • serial port
  • SD card reader (acts as the computers "hard drive")

The Beagleboard Display (using S-Video), browsing the BeagleBoard website.
I plugged in a monitor, USB keyboard and mouse, and connected 5V power and it booted up fine. It all just works.

I am mulling over ideas on how this can be used for the boat's electronic projects. This is purely a research and investigation exercise at the moment.

More later.

Wednesday, November 7, 2012

Main Cabin LED Lighting Module v1.0

The first revision of the main cabin LED lighting control module is done. This module will control strips of RGB (red/green/blue) LEDs for ambient lighting in the main cabin.
Control module with display and joystick

Hardware Features

  • 16x2 character backlit LCD display
  • 2 axis joystick with a press down 'click' switch
  • 12 volt powered
  • USB programmable
  • XBee wireless module 
The insides

Software Features

  • a number of preset "spectrums"
  • 16 step intensity level control
  • on/off switch


  • Push the joystick to toggle the unit on/off
  • Push the joystick up or down to increase/decrease the light intensity
  • Push the joystick left/right to cycle through the set of preset "spectrum" values.
  • The LCD display shows the current spectrum and intensity values


I searched the internet to find some sample RGB values to simulate various types of lighting:
  • "Night Vision Red"
  • "Candelight"
  • "40w Tungsten"
  • "100W Tungsten"
  • "Halogen"
  • "Carbon Arc"
  • "High Noon"
  • "Direct Sunlight"
  • "Overcast Skies"
  • "Blue Skies"
  • "Warm Flrscnt"
  • "Standard Flrscnt"
  • "Cool Wht Flrscnt"
  • "Full Spec Flrscnt"
  • "Grow Lt Flrscnt"
  • "Black Lt Flrscnt"
  • "Mercury Vapor"
  • "Sodium Vapor"
  • "Metal Halide"
  • "Hi-pressure sodium"
Some of these don't really work on this LED strip, as in your eye can't tell the difference between some values. These values can be tweaked via software of course.


The major parts are


Some possible features to be added
  • "remember" the current settings so that a power cycle will reset the unit to the previous state
  • wireless control via the XBee module
  • program custom RGB values via the front panel (no computer needed)