Project Logs

Collapse

• Code

  neil • 08/19/2016 at 14:45 • 0 comments

  This project is written in micropython and can be be found in the following github repositories:

  Main code - https://github.com/coylen/espWIND

  Other dependencies that are shared with the rest of my micropython NMEA codebase - https://github.com/coylen/upyNMEA

  The only additional complexity is that I have had to develop a custom Micropython ESP8266 build to incorporate some very limited I2C Slave support. This is added to Micropython as a driver and can be downloaded and built from https://github.com/coylen/micropython. There is still some work ro be done with this to make the code more robust and timeout as currently it will hang until the circuit sees at least some I2C traffic.

• Bang and smoke

  neil • 08/19/2016 at 13:18 • 0 comments

  So what happens when you solder in a switching regulator the wrong way round so that the 12v supply is going to the output pin and not the input pin?

  Well it would appear that 12v passes straight through the regulator and the ESP8266 does not appear to like a 12v supply to its 3.3 pin. Fortunately I am playing with cheap devices so it is not too costly a mistake.

• Circuit Design

  neil • 08/19/2016 at 13:15 • 0 comments

  So I look around Hackaday and see a huge number of excellent projects with nice colourful custom PCBs which as well as no doubt being the optimum electronic solution also gives an air of professionalism to the project and circuit.

  Unfortunately, I am too lazy/stupid/tight to go down this route for what I fully expect to be a one off as I can't see a wide range of people wanting to do something as niche and specific as the aims of this project. My simple solution for circuit boards is to design them on breadboards and then transfer the proven design to an adafruit perma-proto board. These boards are at the right level of cost and ease of use for someone of my limited electronic capabilities.

  Pictured above is the final circuit for this project, the main components are:

  • headers to accept a Wemos D1 Mini ESP8266 Board with my custom micropython build
  • A P82B96P chip in the centre of the board to level shift the incoming 5V I2C signal from the NASA Marine wind unit to a 3.3v level for the ESP8266
  • A Recom R-78E0.0-1.0 switching regulator to power the circuit from the 12v supply from the Nasa Marine wind unit
  • A Molex connector at the bottom of the circuit to connect to the NASA repeater socket
  • Two dip switches, one on the left allows the regulator to be disabled for when a USB lead is connected to the Wemos for testing/development purposes, and a dip switch on the right which when switched on pulls up a control pin and stops the program from running. This was introduced as it was difficult to break into a running program from the webrepl, although I believe that this may have been a bug which has now been resolved.

  I have no doubt that the circuit could be better designed and implimented, but as a non expert in these areas I am more than happy with a functional design which works as intended.

• ESP8266 I2C Problems

  neil • 08/19/2016 at 12:59 • 0 comments

  Having had the initial pyboard system fail due to my naivety with the length of I2C lines I decided to switch to WiFi transfer of data based on Wemos D1 Mini ESP8266 based units. This was partially due to my just receiving a batch of these units that I had ordered to play with without having a project specifically in mind for them. A booster for the I2C wiring to allow for the long transfer lengths would probably have been more straightforward, cheaper and more reliable. But I guess part of the point of hobby electronics is not necessarily to use the most efficient system, but to play and learn and achieve the goals however we can.

  Had I realised when I made the decision to go with the ESP8266 units that they had no I2C Slave support then perhaps I would have made a different choice. However, having made the choice to go with the ESP8266 the lack of I2C slave support became a new technical challenge to focus on and overcome.

  My challenge was slightly simplified in that the NASA repeater is not a standard compliant I2C Master as it does not require any acknowledgement and just sends its I2C stream at set intervals to provide updates to the connected repeater.

  My initial attempts to implement an I2C slave in python failed miserably, I tried both an interrupt based approach and a blocking read approach and found that neither was anywhere near fast enough to capture the I2C data. This forced me down the road of C code and a custom build of the micropython source.

  Using the existing bit banging I2C master code as inspiration of the structure of C code and the program logic that I had used in my python attempts I was able to implement a very rudimentary routine which provided sufficient functionality for this project.

  Having got this far it is a long term aspiration to develop this code further to provide full I2C Slave functionality and ultimately to pull a full bit banged I2C Driver back to the mainline micropython esp8266 codebase. However, that is a job for another time and another project.

  My micropython fork is at https://github.com/coylen/micropython and the I2C slave code is located in the drivers folder with corresponding changes to the makefile and modesp.c to build and expose the commands to the micropython user.

• Decoding the NASA Sensor

  neil • 08/19/2016 at 12:58 • 0 comments

  Although the work to decode the NASA Wind Sensor was already completed as part of the original pyboard based system, I think that it is of interest and a key part of the project so it is probably worth discussing as one of the key technical challenges that had to be overcome.

  The most recent iterations of the NASA Wind system have a NMEA0183 output stream from the main display unit which outputs the data stream over RS232. This would be easy to intercept and pass into the RPi to be fed over WiFi. However, older units such as the one installed on my boat do not have this functionality, although they do have an output for a display repeater.

  My first inclination was to attempt to find a new display unit which I could swop into the boat. However, despite monitoring ebay and other sources for a while now suitable units became available at a price that I wanted to pay. The alternative was to decode the signals from the existing system. There were two opportunities/possibilities for this:

  • Intercept the raw data from the masthead unit and decode
  • Intercept the data sent for a display repeater and decode at this point

  Whilst the first option is the more direct and straightforward solution, I opted against this as I wanted my system to sit on top of the existing boat systems and not to interfere or compromise them in any way, and teeing off of the signal between the masthead unit and its display head was in my mind an unnecessary risk to the integrity of the system.

  From research on the web I had identified that the repeater output data from the NASA Depth unit had previously been decoded.

  https://translate.google.co.uk/translate?hl=en&sl=de&tl=en&u=http%3A%2F%2Fwiki.openseamap.org%2Fwiki%2FDe%3ANASA_Clipper_Range

  This basically identified the output from the NASA repeater socket as being an I2C stream which contained a burst of data which a standard set of command bytes and data bytes which consisted of a single bit of data for each LCD segment on the display. It seemed reasonable to me that the NASA Marine wind instrument would transfer the data in a similar manner and I attempted to capture the data as a proof of concept.

  Initial data capture with a logic analyser showed two main differences between the data reported from a depth repeater socket and the data captured from the wind repeater socket. These were firstly that the logic data suggested that the SCL and SDA pins of the repeater socket were reversed in the wind unit relative to the depth unit and that the data length was longer (17 bytes vs 11 bytes) in the wind unit. The increase in data length was not unexpected as the display of the wind unit had more LCD segments to allow a complete wind rose to be displayed. However, the switching of SDA and SCL lines was a little bit of a surprise and seemed to have little justification. Perhaps the only sensible reason for this was to ensure that if a depth repeater was plugged into a wind unit or vice versa the data stream would be so invalid that the repeater unit would reject the input rather than display any spurious output.

  Following these investigations a further proof of concept was conducted capturing the I2C data using a pyboard running as a I2C slave device on the appropriate address. This was successful and the next task was to decode and understand encoding on the I2C stream.

  In order to practically decode the I2C stream of data it was necessary to effectively decode the raw masthead data so that I could spoof the data and fool the display into displaying LCD segments of my choice in a controlled manner.

  Once again I was fortunate that someone else had previously decoded the raw output from the masthead unit:

  http://theshipcomputer.blogspot.co.uk/2014/01/the-wind-sensor.html

  This identified that the direction was indicated by two varying analogue values, at any one time, one of these two analogue outputs was at an extreme high or low value, indicating the quadrant and the second varied linearly across tat quadrant. The speed...

  Read more »

• Initial plan/motivation

  neil • 08/19/2016 at 12:58 • 0 comments

  Modern sail boat transducer and chartplotter systems offer advanced features which show optimal tacks and laylines to allow the most efficient and fast routing to the destination to be easily determined. My project aimed to recreate this functionality without the many thousands of pounds required for a chartplotter with this functionality and the new compatible instrument transducers to feed it with the boat performance information.

  Recent plugin developments in the open source PC based navigation software OpenCPN, meant that this functionality was now within reach, my challenge was to get the data from a variety of legacy transducers into the PC system to allow the calculations to take place.

  The boat had three instrument data feeds of interest:

  • An AutoHelm Log
  • NASA Marine masthead anemometer
  • NASA Marine depth gauge

  The challenge was to get the data from these disparate legacy systems onto a wireless Panasonic Tablet running the OpenCPN software.

  The initial system design was based around two main components. A pyboard interfacing with all the instruments through various circuitry sending NMEA0183 output via UART to a Raspberry Pi, which was acting as a boat WiFi Hub and serving the NMEA data via tcp to the OPenCPN.

  In addition to the on board existing instruments, the pyboard circuitry also included a 9DOF compass, accelerometer, gyroscope unit and the RPi had a GPS puck to provide the final pieces of information to allow the tactics plugin of OpenCPN to run.

  However, this system was found to fail as the I2C signals from the NASA Marine instruments (these will be discussed in detail in a future log) were not able to be transferred the length of the boat on wires to the pyboard. To overcome this limitation I had two options, to use circuits based on a P82B96P to boost the signal to allow its transfer over the required distance or to switch to using local ESP8266 modules to decode the signal and then to transfer to the RPi over wifi.

  Whilst signal boosting was perhaps the most straightforward approach I opted for the latter approach which gave rise to this project.

View all 6 project logs