GPS data from Wifly to Android phone (Part 2)

As a proof of concept, I have created a simple app that fetches the last UDP packet received, and displays its contents in a floating message box, each time the button is pressed.

Here is an excerpt of the app's java code that is used for that.

...
public class MainActivity extends Activity {
   ...
   public void sendMessage(View view) {
        new ServerAsyncTask(MainActivity.this).execute();
   }
   ...
   public static class ServerAsyncTask
               extends AsyncTask<Void, String, Void> {
      private Activity act;
      public ServerAsyncTask(Activity _act) {
           this.act = _act;
      }
      @Override
      protected String doInBackground(Void... params) {
         byte[] receiveData = new byte[1024];
         DatagramSocket socket = null;
         try {
            socket = new DatagramSocket(50000);
            socket.setSoTimeout(30000);
            DatagramPacket packet =
               new DatagramPacket(receiveData, receiveData.length);
            socket.receive(packet);
            String contents = new String(packet.getData());
            publishProgress(contents);
            socket.close();
         } catch (SocketException e) {
             socket.close();
         } catch (SocketTimeoutException e) {
             socket.close();
         } catch (IOException e) {
             socket.close();
         }
         return (Void)null;
      }
     
      @Override
      protected void onProgressUpdate(String... str) {
         Toast.makeText(act, str[0], Toast.LENGTH_SHORT).show();
      }
   }
} 

GPS data from Wifly to Android phone (Part 1)

Once an Access Point has been created on the phone with the app described in the last post, we can use the app’s data to configure the RN-XV module. Let's keep the same example:

            - SSID :                     DIRECT-6U-Android_37e5

            - passphrase :           sK2QIENk           
            - phone’s IP :            192.168.49.1

Here is the arrangement used to configure the RN-XV module:

  Only 4 pins will be used on the RN-XV module:

• pin 1 (red) : VDD_3V3
• pin2 (yellow) : UART_TX
• pin3 (green) : UART_RX, with an external 10k pull-up to 3.3 V
• pin 10 (black) : GND

The module is connected to a laptop running TeraTerm through a USB-to-Serial converter. Here, we use the Adafruit's USB to TTL Serial Cable. Note that the converter's red wire should NOT be used, as it is connected to the USB 5V power, which could damage or destroy the RN-XV. The TeraTerm monitor software is configured at 9600 baud, which is the default for the RN-XV UART.

 

Once connected, the following commands are sent to the RN-XV module:

 

$$$
factory R
reboot

 

$$$
set wlan ssid DIRECT-6U-Android_37e5
set wlan passphrase sK2QIEnk
save
reboot

 

$$$
set ip host 192.168.49.1
set ip remote 50000
set ip proto 1
set comm time 10000
set comm size 75
set comm match 13
save

reboot

 

With this configuration, the module will form and send a UDP packet from the already received data each time any one of the following conditions occurs:

• 75 bytes of serial data has been received by the module through the UART_RX pin;
• or the ASCII character 13 (carriage return) has just been received;
• or 10 seconds have occured since the last packet has been sent.

In the following arrangement, a GPS NMEA output at 9600 baud is connected to the UART_RX pin, and the RN-XV module continuously forms and sends UDP packets with the GPS data. Each packet will contain a complete NMEA sentence, as these sentences all end with the carriage return byte, and are less than 75 bytes.

 

 

 

Our next step will be to create an Android app for the phone that will capture the packets, retrieve the GPS data and display the info on the screen. 

 

 

Talking to an Android phone through Wi-Fi

In this system, the master controller sends its serial data to a laptop through a USB-to-Serial converter.  The laptop is responsible for creating a number of colorful animated displays from this data. Now I am interested to send this same data to an Android phone that can create its own custom displays. This can be done either through Wi-Fi or Bluetooth.

I want to implement both, by double-splitting the UART Tx line to a RN-XV Wifly Module, and to a BlueSMiRF Bluetooth Modem.

In this post, I will discuss the Wi-Fi route.

The goal is to establish a peer-to-peer adhoc connection between the Wifly module and the phone, and to use UDP packets to keep a low latency in the transmission of live 10 Hz data. Since Android 4.0, it is possible to programmatically configure the phone as an Access Point (AP) visible to nearby Wi-Fi modules (including those integrated in most modern laptops and computers).

There is currently a limitation to this approach (but see UPDATE below!). In creating the AP, the Android system assigns a random SSID and passphrase to it, and it is not possible to edit these values The Wifly module must have an advanced knowledge of these values in order to connect to the phone. So the AP must first be created by the phone, and its details made visible in order to configure the Wifly module.

I have created a simple app tool to assist in this task. It is available on Google Play under the name ‘Wi-Fi P2P Access Point’. I have set up a small fee to refrain people to install it without having a real interest and knowledge of what it is designed for.

With this application, you can create an access point that will live as long as Wi-Fi is enabled on the phone, or until you manually remove it in the app, or until the Android system arbitrarily decides to destroy it to reclaim resources.

Here is a simple way to test if the AP actually exists. After you create an AP, your laptop will automatically list it as an available network, and if you want to connect, you will have to provide the passphrase. Once connected, nothing more happens because there is no data flow on the connection.

Avoid rapidly creating and removing APs without some pause between the commands. The app will become unresponsive and you may have to disable and re-enable Wi-Fi.

In coming posts, as an intermediate step, we will look at:

- how to configure the Wifly module to send GPS data to the phone;

- how to develop a custom app than can display these data.


UPDATE: With Android 4.2.1, the above limitation seems to have disappeared! The SSID and passphrase remain the same when the access point is removed and recreated.

Compass calibration on the water

Even if an electronic compass has been meticulously calibrated on land in a non-disturbed magnetic environment, it will need additional calibration adjustments once installed in a boat.

In a previous post, I described a procedure to recalibrate a compass with a GPS if you can find a patch of water where there is absolutely no current, a situation that practically does not exist in my maritime environment.

If your system can log the headings from a fast compass (5 Hz or more), here is an alternate method that can tolerate an existing current, but requires absolutely flat water (no waves) and no (or very negligible) wind. This is in fact the method that many commercial compass vendors choose to implement in their autocalibration routines, but presented here in a transparent manner.

These conditions must be met: a low and constant motoring speed (2 to 4 knots), and a tiller or wheel blocked in position so that a complete turn will take around 3 minutes.

Here is how I produced the results presented at the end of this post.

I made several turns while logging the headings (for both the Aimar H2183 and my own Hi-Resolution compass), as well as the boat speed. From the speed log, I find a section where the boat speed has been very stable, and I extract the heading data from a full turn.

We can make the reasonable hypothesis (with no waves and no wind) that our angular velocity has been constant during this golden turn, so that all recorded headings have to be separated by equal angles. If this is not the case, we can calculate the local deviation.

So several turns are recorded, but only the best one is used in the calibration. Here is simplified example using only a reduced set of measurements.

In Colum A, we have the measured headings on a complete turn, with 20 diffferent measurements. The expected angle difference between each measurement is 360/20 = 18 degrees. In Column B, we have calculated these expected headings if there was no deviation. In Column C, we calculate the deviation (A – B).

We can graph these deviations (C) vs. the measured heading (A). This is our deviation graph.

From these data points, we can calculate (using the NLREG software)  the 5 deviation coefficients (A, B, C, D, E) such as that:

Deviation = A + B sin(H) + C cos(H) + D sin(2*H) + E cos(2*H).

By correcting the measured heading by the calculated deviation, we obtain a pre-calibrated heading that still needs a last offset correction.  Our graph is based on the assumption that there is no deviation at our starting heading of 100 deg. But this is not necessarily the case; the zero-deviation point(s) may be at some other heading(s).

This last correction is easy to do, as we need only to compare any pre-calibrated heading value to a known heading. For example if, with the boat aligned along a dock at 78.0 deg, we obtain a pre-calculated heading of 76.5 deg, we will have to add a constant offset of 1.5 deg to all our pre-calibrated headings. (Don't trust your regular magnetic compass for this : it has its own uncorrected deviations).

Final corrected heading  =  Measured heading  - Deviation + Offset 


Here are the deviation curves obtained from my 2 compass, using data from the same turn.


Airmar H2183 Compass  (1721 meassurements, doubled 5 Hz samples ):

Hi-Resolution Compass (1737 measurements, 10 Hz samples):

 
So are we done?

Not really, because be still have to check if this calibration remains valid:
 - when the motor is not running
 - when the boat is heeling.

Getting an accurate magnetic heading is a never ending story.

Interfacing the Raymarine ST1000+ Autopilot

I understand that the Raymarine ST1000+ autopilot (and the similar ST2000+) can receive exterior heading data through the SeaTalk bus, specifically from a Raymarine ST40 fluxgate compass. So another project would be to use the heading output from my hi-resolution compass to drive the autopilot.

First I was interested to see what kind of data the autopilot puts on the SeaTalk bus as a talker. I used the following arrangement to monitor the SeaTalk bus.

The autopilot is connected to a serial port of a MAVRIC-IIB board through the SeaTalk interface circuit. The MAVRIC-IIB has an onboard MAX222 chip to provide level conversion between the serial port and the logic level pins of the ATMega128 microcontroller. The SeaTalk datagrams showing on the bus are resent in hex format to a computer running Hyperterminal, through a serial-to-USB converter.

The microcontroller code is an almost direct port of the “SeaTalk Monitor” code available on Thomas Knauf’s website. It can be found at the end of this post. In normal operation (standby or auto), the ST-1000+ sends continuously these 2 datagrams, each one at 1 Hz, with a half-second between them.

…
9C C1 07 00
84 C6 07 00 00 00 00 00 0F
9C C1 07 00
84 C6 07 00 00 00 00 00 0F
9C C1 07 00
84 C6 07 00 00 00 00 00 0F
9C C1 07 00
84 C6 07 00 00 00 00 00 0F
…

Here, the 9C datagram encodes the compass heading (in degrees) and the turning direction (left or right).

The 84 datagram also encodes the compass heading and turning direction, plus the autopilot course when in auto mode, and the currently active mode (standby, auto, vane or track mode).

We learn on Thomas Knauf’s site that the 89 datagram encodes the compass heading sent by the ST40 compass instrument, and can be read by the ST1000+ or ST2000+ autopilot. To test this behaviour, I modified the microcontroller code (not shown here) so that it sends an 89 datagram (89 02 04 00 20) after reading each of the 9C and 84 datagram, with a small delay to avoid collisions. The datagram sent (89 02 04 00 20) encodes a heading of 8 degrees.

The monitor then produced this kind of ouput:

…
9C 01 04 00
89 02 04 00 20
84 06 04 00 00 00 00 00 0F
89 02 04 00 20
9C 01 04 00
89 02 04 00 20
84 06 04 00 00 00 00 00 0F
89 02 04 00 20
…

From what I observed by playing with the autopilot in standby and auto mode, the 89 datagram is interpreted by the ST-1000+ as a request to perform a heading alignment to the value encoded in the datagram.

So if a custom heading is encoded in an 89 datagram sent on a regular basis, the autopilot will indeed adjusts its heading alignment if required to reproduce this value.


#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdio.h>
unsigned char resh;
char buffer[256];
char hex[]="0123456789ABCDEF";
unsigned int collision_ctr;
unsigned char in_ptr, out_ptr, limit_ptr;
char receiver_buf, byte_ctr;

unsigned char kbhit(void)
{
 // return nonzero if char waiting
 unsigned char b;
 b = 0;
 if(UCSR1A & (1 << RXC1))
  b = 1;
 return b;
}

int uart_putchar0(char c)
{
 loop_until_bit_is_set(UCSR0A, UDRE0);
 UDR0 = c;
 return 0;
}

int main(void)
{
  in_ptr = 0;
  out_ptr = 0;
  limit_ptr = 0;

  /* enable serial port UART1 */  /* Set baud rate : 4800 @ 16 MHz */
  UBRR1L = (unsigned char)(207);
  /* Enable receiver with 9 data bits  */
  UCSR1B = _BV(RXEN1) | _BV(UCSZ12);

  /* enable serial port UART0 */  /* Set baud rate : 9600 @ 16 MHz */
  UBRR0L = (unsigned char)(103);
  /* Enable transmitter  */
  UCSR0B =_BV(TXEN0);
  for(;;)
  {
    if(kbhit())
    {
      // check 9th bit before reading UDR1
      resh = UCSR1B;
      resh = (resh >> 1) & 0x01;

      receiver_buf = UDR1;
 
      if(resh)     //  9th bit set
      {
        if(byte_ctr)   // More characters expected => Collision
        {
          in_ptr = limit_ptr;    // Discard last datagram, restart from beginning 
          collision_ctr++;     // Count collision events 
        }
        buffer[in_ptr++] = '\r';  // Put new command on new line 
        buffer[in_ptr++] = '\n';
        byte_ctr = 255;  // Undefined datagram length, wait for next character
      }
      else
      {
        if(byte_ctr == 254)       // Attribute byte ? 
        byte_ctr = (receiver_buf & 0xF) + 2; // Read expected datagram length
      }
      if(byte_ctr)
      {            // Process valid data bytes, should always be true 
        buffer[in_ptr++] = hex[receiver_buf >>  4]; // Convert Data to hex 
        buffer[in_ptr++] = hex[receiver_buf & 0xF];
        buffer[in_ptr++] = ' ';                     // Seperate by space 
        if(!--byte_ctr)
          limit_ptr = in_ptr;        // Complete datagram ready for output
      }
    }
    else
    {
      if(out_ptr != limit_ptr)          // Characters waiting for Output ?
      {
        // Copy single character from buffer to screen
        uart_putchar0(buffer[out_ptr++]);
      }
    }
  }
  return 1;
}

Building the 3 MHz ultrasonic transducer

A first 3 MHz transducer prototype is ready for testing. A vintage Airmar ST200 speed transducer housing has been modified to receive the piezoelectric element.

WARNING: this particular transducer design is not intended to be installed on a real boat for safety reasons. The threads between the compression ring and the housing may be stripped following an underwater impact, causing massive ingress of water. This design is intended to be used only for development purposes on special floating devices.

A future improvement will be to modify the form of the yellow urethane matching layer so as to get rid of the recess. This first prototype will be used mainly to test the electronics outside of a real boat, so that the safety epoxy plug will not be cast for the moment, in order to keep full access to the transducer.

I was fortunate to get the help of a competent machine shop owner to achieve this. Here are some pictures.

Designing an ultrasonic transducer

Here is the conceptual design of the 3-MHz ultrasonic transducer. Apart from the piezoelectric element, the 2 important design parameters are the nature of the backing and matching layers.

Air is a good absorber of high-frequency ultrasounds, and has been chosen as backing layer. The matching layer will be a sheet of urethane (40 A Durometer), available from this source.

The first step has been to characterize the piezoelectric element. Two wires have been soldered to the piezo’s silver platings.

The following arrangement has been used to measure the resonance and antiresonance frequencies of the piezo disc. The frequency generator is first adjusted to give a maximum voltage across the resistor: this is the resonant frequency, where the piezo impedance is at its minimum. The frequency is then increased until a minimum voltage is measured: this is the antiresonance frequency, where the impedance is at its maximum.

The results of these measurements are as follows:

            Resonance frequency:           2,932,000 Hz
            Antiresonance frequency:     3,345,000 Hz

The resonance frequency is where the piezo element converts with the highest efficiency the electrical energy into mechanical energy. This will be the design frequency of the transducer. Note that these frequencies are for the unloaded piezo in free air. When the transducer will be completed, the resonance frequency will be measured again with the transducer in the water.

The powerful (and free) BioSono KLM software has been used to model the transducer performance. From the physical description of the transducer components, this software will calculate a whole range of outputs, including the resonance and antiresonance frequencies and impedances.

The model is in very good agreement with the measured frequencies, and calculates a resonance impedance of 0.37 ohm. This is in line with the piezo manufacturer figure of less than 1 ohm.

The design goal is to transmit a peak power of 12 W to the transducer. This means that during the pulses, a high-frequency AC current of 5.7 amperes will flow through the transducer. Usually, an impedance matching circuit would be placed inside the transducer housing so that the amplifier will see an impedance of 50 ohms with a reduced current ouput. The BioSono KLM software can be used to calculate the required impedance matching circuit.

However, for this project, the decision has been made to use a high-current Class-A amplifier with an output impedance matching the piezo’s impedance of 0.37 ohm.

There are 2 main advantages for this unusual design:

a)  The ouput current to the piezo will be a pure sinewave instead of the typical square wave used in continuously transmitting ultrasonic applications;

b) The amplifier will use a standard marine power supply voltage of 12 V.  With a higher impedance, a higher voltage power supply would be needed.

Class-A amplifiers are well known for their high-fidelity but poor efficiency (as low as 15%). In this application, this efficiency penalty is not significant, because the length of the pulses will be very short. Even with an instantaneous transmitting power of 12 W, the average consumed power will much less than 1 watt.