NMEA4Wifi NMEA Input

Discussion and support for the Nmea4Wifi multiplexer - a 4-input Nmea 0183 wifi multiplexer.
Post Reply
sagwin
Posts: 5
Joined: Sun Dec 30, 2018 8:53 am

NMEA4Wifi NMEA Input

Post by sagwin » Wed Feb 13, 2019 4:20 pm

Hi Luis,

just received the multiplexer :D and now I am fiddling around with the wiring.

Regarding the output of the multiplexer, I am not sure how to find out if my furuno GP31 GPS has an opto-isolated input or not. Do you have a hint where I can get this info from?

Thx

Regards,

Julian

Luis Sa
Site Admin
Posts: 175
Joined: Thu May 04, 2017 4:12 am

Re: NMEA4Wifi NMEA Input

Post by Luis Sa » Wed Feb 13, 2019 6:21 pm

Hello Julian,

Are you pretending to send data from the multiplexer to your Furuno GPS unit? Or the reverse? Note that with Nmea0183 you can have only this:

one talker sending data to one (or more if the talker has sufficient drive capability) listener

Normally a GPS sends data, that is to say, it acts as a talker.

I could not find information about your GPS. If you want send me a drawing of what you trying to achieve.

Regards, Luis

sagwin
Posts: 5
Joined: Sun Dec 30, 2018 8:53 am

Re: NMEA4Wifi NMEA Input

Post by sagwin » Thu Feb 14, 2019 8:44 am

Hi Luis,

attached a drawing of my wiring, the wiring map of the GPS/plotter and a glossary for the wiring terms.
I would like to connect the output of the multiplexer with the input of my Furuno GP31 to be able to track the route and waypoints, which I set in my app also on the display of the Furuno GP31.

Additional question:
I set up the windows tool on my Laptop and connected to the NMEA4Wifi network, which worked fine. I also could update the firmware. However, I was not able to receive the AP data. Checking my wifi, I am connected with the mutiplexer and the firewall allows communication through all ports and protocols. What could still be missing?

Thanks for your help.

Regards,

Julian
Attachments
Furuno GP31 Glossary für Verbindungsdiagramm der Bedienungsanleitung.docx
(14.39 KiB) Downloaded 36 times
Furuno_wiring.JPG
wiring.jpg

Luis Sa
Site Admin
Posts: 175
Joined: Thu May 04, 2017 4:12 am

Re: NMEA4Wifi NMEA Input

Post by Luis Sa » Wed Feb 20, 2019 10:24 pm

Hello Julian,

I am sorry not to comment on your post earlier. I hope that you were able to sort out your wiring. Here my late comments:

1. The safe way is to use A5 and GND on the Nmea4Wifi output. It should work without problems. To use A5 and B5 you would need to be sure that the Foruno input is opto-isolated. And for the usual distances of less than 10 meters between the talker and listener there will be little difference with regard to noise reduction.

2. When you say " receive the AP data", I assume you mean receive data transmitted by the multiplexer over its own network (default SSID = NMEA4WIFI). If that is so and since you were able to communicate with the multiplexer (and update the firmware) you need to check all your settings. There are many unknowns. Were you using UDP or TCP? Which data are you transmitting? I am sorry but the only thing I can say is try to advance by little steps. I admit that the tool could be confuse but you can do powerful tests with it. You can do, for example, a loop back by Wifi, reading a file, sending it out from the PC to the multiplexer, set the multiplexer to send it back to the PC, save the received data into a file and, in the end, compare the original file withe the received file. I used the tool extensively during the tests.

Once more my apologies for the delay in the answer. You can always contact me directly at luis at vela-navega dot com.

Regards, Luis

sagwin
Posts: 5
Joined: Sun Dec 30, 2018 8:53 am

Re: NMEA4Wifi NMEA Input

Post by sagwin » Fri Apr 19, 2019 7:03 pm

Hi Luis

sorry for my late update. I took until that I could test at my boat with live data. Can receive nmea data on my phone from all device. This is great. :D

I am wondering why the data transmission is quite slow. Data via WiFi is displayed 10-20 seconds late. But not always. Any thoughts on this one?

Regards Julian

Luis Sa
Site Admin
Posts: 175
Joined: Thu May 04, 2017 4:12 am

Re: NMEA4Wifi NMEA Input

Post by Luis Sa » Fri Apr 19, 2019 7:54 pm

Hello,

I am happy that you got your setup running. Regarding the delay via wifi, I have no idea. As soon as the multiplexer starts, and after a initial setup, it enters an infinite loop as shown in the code below. Basically for all the 4 wired inputs and for the UDP and TCP inputs, it tests if a character has arrived (note that at 4.800 baud, for example, each character takes about 2 miliseconds to arrive which is a very long time for the processor!). If no character has arrived on a particular input it goes to the next input. If a character has arrived and it is the end of Nmea 0183 sentence, a boolean flag (line_1 line_2 ...) is set as true so the next instruction will output the whole received sentence. There is no input buffer or delay.

The only problem can occur when outputting. There is an output buffer with a size of up 4 Nmea 0183 sentences. If you are receiving data at very high baud rates and the P5 output port is sending the combined data at low baud rate then the referred to buffer will soon be full. When a received sentence can not be placed in the buffer because it is being empty slowly and there is no space for it, the sentence will simply be dropped (ignored).

The previous paragraph refers to serial output. With wifi output you must be carefully with the TCP protocol. This protocol is heavy and has error corrections. A sentence, if not received, or if received with error (noise, poor connection, long distance, ...) can be requested to be resent again. This could lead to a long time for the Output_T routine (the one that sends over TCP) shown in the code to return. This could impact the performance but not the delays that you are referring to. This problem lead me to limit the number of TCP connections to one. On the contrary UDP is fast! The UDP packet (a Nmea 0183 sentence) is just sent by radio and the multiplexer will not wait for a receipt acknowledgment. I prefer UDP for these reasons.

Also refer to the filtering possibilities to avoid non needed sentences to be transmitted or received. This will alleviate the multiplexer.

Finally, it could also be the case that the receiving app takes time to process the received sequences before showing the result on the display. I do not believe that is the case. 1 or 2 seconds could be but not 20 seconds.

I am sorry for not being more assertive. I will flight to Greece tomorrow to start this year sailing season!

Regards, Luis

Code: Select all

void loop() {
  server.handleClient();
  // check if TCP connection is available
  if ( tcpport > 0 ) { IsTcpClient = Test_T_Connection(); }
  else { IsTcpClient = false; }
  yield();
  // test inputs and output
  if ( Input_1 ) { Test_Serial_1(); }     // check if Hardware Serial port #1 is available
  if ( line_1 ) { Output_1(); }           // output to wifi and/or serial
  if ( Input_2 ) { Test_Serial_2(); }     // check if Hardware Serial port #2 is available
  if ( line_2 ) { Output_2(); }
  if ( Input_3 ) { Test_Serial_3(); }     // check if Software Serial port #3 is available
  if (line_3) { Output_3(); }
  if ( Input_4 ) { Test_Serial_4(); }     // check if Software Serial port #4 is available
  if (line_4) { Output_4(); }
  if ( Input_U ) { Test_U(); }            // check if udp packet is available
  if (line_U) { Output_U(); }
  if ( IsTcpClient ) {                    // check if tcp packet is available
    if ( Input_T ) { Test_T(); }
  }
  if (line_T) { Output_T(); }
  Test_WebClient();                       // Check if a web client has connected
  Test_Reset();                           // check if reset pin is LOW
  if ((millis() - timer) > twdg) {
    DoWatchDog();  // check state of the system
  }
}

Post Reply