Saturday, March 12, 2016

ESP8266 Design Contest Entry NMEA Bridge for OpenCPN

 !! Update edited Fritzing schematic Apr 28,2016 !!

 
Everything ESP8266  had a Design Contest In March 2016. The following was my entry, viewable at http://www.esp8266.com/viewtopic.php?f=152&t=8738



An ESP8266-01 WiFi module to read NMEA marine serial data and UDP broadcast it to multiple openCPN instances as a Bridge.

On my boat and several others, we are running OpenCPN for navigation software. Most of us run it on a laptop. The common inputs are GPS, AIS and some have all their instruments connected as well; depth, wind, speed & distance log, etc.

There are two problems that I am trying to solve. First, too many cables to the laptop providing the instrument data. And second, a way to share the instrument data with multiple devices. The release of opencpn for android tablets and smart phones makes it feasible to have multiple displays around the boat. Like in the captain's bunk to check on the boat and crew performance without getting out of bed.

So this friend that wants all of the instrument data over the network has a multiplexer that takes his SeaTalk and various NMEA 0183 signals and outputs a higher baud NMEA sentence data stream. And I have a combination AIS/GPS that has NMEA 0183 at 38400 baud. My laptop is getting old and if you touch the USB cable from the RS-232-to-USB it disconnects and reconnects using a different port configuration.

And besides it would be nice to have no cables, especially to a phone or tablet.

Along comes the ESP8266 Serial WiFi module with a modest price around $2.50 USD and other board configurations for a few dollars more.

So the plan is to create new firmware for the module, connect the rs-232 based NMEA 0183 signals to it and broadcast the sentences over the WiFi as UDP packets on the local subnet. So this will require a WiFi Access-point (AP) on the boat. (ED. It may be possible for the ESP to be the router too.) Another recent development is the availability of cheap pocket routers such as the TP-LINK WR702N. I picked mine up in Singapore for less than $8.00 USD last year, but the market is full of competitors.
I want to be able to run openCPN on both a laptop and a tablet at the same time. I would like the laptop down below deck, safe from the rain and salt water spray. I would like to have a mostly waterproof tablet in the cockpit to monitor progress. And I would like to be able to quickly check the ship's status from the captain's berth when off watch, maybe on a smart phone.

I decided to implement a device to read the serial data from all the boat instruments and send that data to openCPN over a WiFI link so there are no physical wires attached. It will broadcast the data with UDP so that multiple devices can read the data at the same time.

The ESP8266 ESP-01 was chosen because it was on hand and it has adequate I/O for this project.


NMEA 0183 is usually rs232 or rs484 at 4800 baud. The rs-232 input signal voltage should work with -12 to +12 volts. This project was tested with a Garmin 72H which outputs -5 to +5 and 4800 baud and an OceanPC AIS which outputs -3.0 to +3.0 at 38400 baud. Therefore, after a little search, I found a single transistor level shifter for the Rx input to make it conform to the 3.3v TTL levels of the ESP module.



Figure 1a. Strip-board implementation


Figure 1b. Strip-board bottom

The +5v power (from a 12v automobile USB charger module) comes in through the switch, upper left then a 3.3v regulator and then to the ESP module's socket. It is a little sensitive, so pull-up resistors are recommended on the 3 data lines, GPIO2 and Rx) and the chip select and reset pins. Tx and Rx are needed for programming (flashing) the firmware, and as a development board I chose to bring those to the top right pins with a ground for a future test of a 16x2 serial display.




Figure2. Schematic

The LEDs and pins at the bottom show the state of the 2 GPIO lines. The software configuration technique uses a short between these to go into config mode. The push button puts the module in flash mode.

First Usage

Connect power lines and input signal rs-232 line with ground. Press and hold config button, press reset, continue to hold config until the LED stays lit. Connect to the AP "NMEA WiFi Bridge" with a system/phone/etc. Connect your browser to 10.1.1.1 with password in code "nmeawifi".` Configure the form for your network and click the "configure" button. Verify the results page. Press reset or cycle power for the module to connect to your network.

To verify it is working, there is a status page on the address on the NMEA WiFi Bridge. Type this address into your browser.

The design of the code has three parts: setup configuration, normal execution and a status webpage.

First, setup configuration, short GPIO0 to GPIO2 (press the config button) and turn on the power. After a few seconds (5-6) the LED comes on indicting the module is ready to configure. This starts an AP at 10.1.1.1 that you can connect to with a WiFi capable device (laptop or phone or tablet using DHCP), then access the webpage at that IP. You get page_1.jpg.




figure 3. Setup


Enter the ssid and password for your boat network, the UDP port to connect and the baud rate to listen for the NMEA data.

When you click configure, it displays a confirmation of your data. If it is correct, turn off the power, connect it to you NMEA data, remove the short between the GPIO pins (do not press the button) and turn on the power.



Figure 4. Confirmation

The second part of the code, normal execution, now runs. It listens for NMEA sentences and when it has a complete sentence, broadcasts it to the broadcast address of the subnet you provided in config. All devices on that subnet can read these UDP packets.

Now go to your opencpn configuration settings, then connections. Add a new connection, selecting: network, UDP and the port number from above (default is 10110).
You should be getting data.



Figure 5. Status

The third part consists of a status page. You can look in a web browser at the IP address of the NMEAWiFiBridge and get a status page that updates the number of sentences broadcast every 10 seconds. It may severely impact the ability of the ESP to keep up with a busy data stream to monitor it, so it is only there to help with trouble shooting the connections. It should only impact performance while your browser is displaying the page.


  Figure 6. Rev 3 installed

Since the initial build I have made custom boards (3 trys to get them right) and have 2 installed and running aboard the Katie Lee.

See my github repository for code and schematics: https://github.com/svkatielee/NMEA_WiFi_Bridge  https://github.com/svkatielee/NMEA_WiFi_Bridge

The configuring software is based upon the work of Forward Computing and Control. My hardware is open-source, my software is GPL3.

Parts
1 - ESP8266-ESP-01
1 - LD1117-33 regulator (any 3.3v > 500ma will do)
1 - 1uF tantalum
6 - 4.7K ohm pull-up resisters
1 - 330 ohm current limit for Tx buffer
1 - 10K ohm for rs232 level convert 1 - 2n2222 for level convert
1 - 1N5819 program Rx input
1 - LED
3 - momentary pushbuttons

Links
Code and schematic on Github

21 comments:

  1. Why am I getting a "NMEAWiFiBridge:529: error: cannot convert 'String' to 'const char*' in initialization" error when I try to compile this?

    ReplyDelete
    Replies
    1. Hello Long John,
      Not sure, but several things in the environment are changing rapidly. Check the revisions of all the software. It still compiles OK with the Arduino IDE for ESP 1.6.5 and the board manager version 1.6.5-947-g39819f0. Also version 1.9 of the library pfodWifiConfig.zip.

      Other revisions get different compiler errors. For instance 1.6.8 doesn't like the SoftwareSerial in pfodWifiConfig.

      Delete
    2. Long John, I also now get this error in the environment I had compiled OK before.
      The problem is to convert a c++ string to STD c string.

      I do not have a board to test just now, but it compiles if I change the const char* scanForAPs() { function to
      ...
      String ssid_scan = WiFi.SSID(i);
      ...
      strncpy_safe((char*)ssid_found, ssid_scan.c_str(), MAX_SSID_LEN);

      Also see the later posts: http://kb7kmo.blogspot.com/2016/03/esp8266-design-contest-entry-nmea.html

      github updated June 30, 16

      Delete
  2. Thanks for the fast reply

    This seems to be a common C++ error so maybe the IDE is more strictly enforcing the rules. (I hate C++ ... It's as strict as a spinster school teacher and even less forgiving) I'm going to see if I can rework the syntax in that line of code before I go to the trouble of installing another instance of the Arduino IDE and all of that.

    If I come up with something I'll let you know .... If you don't hear from me again then assume I went with your suggestion of installing the known working versions and didn't find a workaround/new syntax ... That doesn't mean one doesn't exist, just that I'm too much of a hack to figure it out myself .....

    Thanks for the help and the code, this is a minor problem compared to me trying to hack all this code together myself .... When I looked into this a year ago everyone was still just trying to translate the Chinese datasheets and using these with an Arduino which is obviously redundant in most cases

    ReplyDelete
  3. I got this going finally, I forgot my laptop still had 1.6.4 on it so I programmed it from there.

    One thing I did notice in the schematic is R2 should be dropped because R7 already pulls up the RX input and having R2 in parallel with it is not only redundant it lowers the resistance in half and thus doubles the current. Granted it still pretty small it's still bad design form especially if you are trying to go as low power as possible

    Just a tip from an Electronics Engineer .... Other than that, great idea providing pullups on all I/O so they don't end up in an undetermined state . It's a common design error by the lesser experienced to leave them out .... Once you spend days troubleshooting an intermittent problem caused by not using a pull up resistor you'll never forget to use one again. Of course I've never made that mistake myself, it's just what I heard (OK maybe it did happen to me .... but only once)

    Great project and worked flawlessly for me once I got around the programming glitch

    ReplyDelete
  4. Long John, Glad you had success. Thanks for pointing out the resistors. Turns out that only the copy of the schematic here, in fritzing, is the only one I didn't remove the extra resistor. In the eagle files (even all my earlier revisions) it is not there. I need to update this copy.

    ReplyDelete
  5. I documented a RS-422 version of this circuit I'm using on an Lowrance Elite 7 Ti. Details on my blog

    The Netbook2Chartplotter Project
    http://netbook2chartplotter.blogspot.com/

    ReplyDelete
  6. Hello, very nice work. I was wondering if you support bi-directional NMEA at this stage. Because I'd be interested to output data to my tillerpilot also. (My plan is to embed another ESP8266 within the tilletpilot case to make it a "wifi" tiller pilot :) )

    ReplyDelete
    Replies
    1. No I have not. First you will need to evaluate the need to change the buffer circuit for the transmit pin. See: http://www.scienceprog.com/alternatives-of-max232-in-low-budget-projects/ as noted in the github README. Then add the code for sending. It should not be too complicated. I just have no need in my setup. Also see the comments on my first post https://kb7kmo.blogspot.com/2015/09/nmea-wifi-bridge.html

      Delete
  7. Nice work Larry. I have the code compiled and working on a D1 Mini (please forgive my laziness :)). I needed to remove the second call to start the Serial interface as the most recent SDK seems to be intolerant and crashes. Works like a charm!
    I also decided to use Software Serial - a trivial change.
    I'm not breaking out position, time and speed and sending them via MQTT so that my other devices can use the information as necessary.

    Thanks again

    John
    S/V Amazing Grace

    ReplyDelete
    Replies
    1. Thanks John,
      Glad it was a help. I had not noticed the D1 Mini before. Do you document your stuff somewhere?

      Larry

      Delete
  8. I can do - I have some other projects at kk4oyj.wordpress.com. Going to have a few frantic weeks of work but I will document it when I get time in December. I use the MQTT time from the GPS to drive a custom freezer controller so it switches off and, more importantly ON again after HF nets.

    ReplyDelete
    Replies
    1. Sorry to take so long to approve this comment...

      Delete
  9. Hi again Larry, I thought I had answered your last comment but as I return to the page I see that it is missing. I do document, from time to time, my projects. However, I'm so ashamed of my code that it doesn't appear on Git.
    I have a question. I was starting to use the D1 mini running my version of your code (using SoftwareSerial for the port to the GPS) to feed my on board MQTT server. The code runs fine while feeding OpenCPN but, I found the messages became erratic at the node-red/MQTT end. (I want the time and a few other parameters to run stuff on-board).

    I was wondering about the purpose of the delay(10) in the main loop? Removing it and relying on the yield() statement further down seems to have solved the problem.

    ReplyDelete
  10. Hi John, If I remember correctly the delay was just there to slow the spin when nothing else happened in the main loop during testing. I would replace it with another yield() instead of just deleting it. In the versions I tested with the cpu needs time to manage the wifi activities so the delay and the yield both give it time to run in a similar manor. With no real delay I thought that when the if statements were all false it would go through the loop too often. I was probably wrong.

    Don't be embarrassed about your code, nobody likes the code they wrote a few years ago. For new guys trying to learn code they need to read lots of code, good and bad, to learn. Github has ample provisions for documenting the quality of your code in the README.md and other notes. Just mark it temporary experimental and possibly ask for improvements in the readme.

    ReplyDelete
  11. Hi Larry, Good to hear from you. Another question I had was that the patterns available for the customisation of the UDP port don't seem to work correctly on the higher numbered ports (e.g. 55556) required for some other projects like SignalK and freeboard. Perhaps you could suggest an alternative.

    Regarding the code, its really all yours with only a few modifications so I'm not sure it warrants me forking it. Perhaps you might want it as a separate version in your repository?

    ReplyDelete
  12. Looking at the code I don't see the problem. It starts as a unsigned int. Then converted to uint16_t then as a 5 char string in EEPROM and back. All of which should be 5 digits. Must be something other than data type issue. I only tested in Linux and with tp-link routers. I also only tested with ports around 10110. Other problems have been because the newer arduino IDE follows more strict c and c++ standards.

    ReplyDelete
  13. Hi again Larry. The problem is at the point of saving the config. When you save it - the specified port changes.

    ReplyDelete
  14. We are just launching the boat after 1 1/2 years in the work yard so I will not have time to investigate this for a while. Forward Computing has had sereveal revisions since the version I chose. Possibly one addresses this. There were other incompatibilities reported however. The newer IDE is more strict about data type conversions. This is where i would start looking.

    ReplyDelete
  15. Hello!

    Does your NMEA bridge has capability to send data from nmea instrument and nmea ais via wifi to android phone running opencpn and receive nmea message from android phone opencpn for autopilot and output this message on nmea port?

    thanks and best regards!

    ReplyDelete
  16. No my implementation is one way only. It only receives from the GPS or AIS and broadcasts over wifi. It does not receive from opencpn. The ESP-01 only has one port. You could add that capability if you used a module with more ports, like an ESP7 or 12e. or use a 3rd ESP-01 just for the autopilot, with new firmware of course.

    ReplyDelete