Connecting to router in STN mode breaks NMEA out on p5

[Luis Sa]

Hello Paul,

An oscilloscope could indeed reveal some differences in the P5 output waveform but it would be difficult to interpret them. The idle state of the waveform is LOW (about 0 volts) and when data is being sent out, it alternates between 0 and 5 volts. It will be difficult to derive the bytes (and even more difficult the nmea0183 sentences, if any are sent in "router mode") from the varying waveform. By " router mode" I mean when you also connect to an external network.

I have discussed your problem with Dagnall and if any of us has a suggestion, we will, for sure, let you know. In addition to what has already been discussed, there is something that perhaps could be useful. I understand that your wiring is very well assembled and you do not want to disassemble it But I notice that you the USB socket is easily available. There is an undocumented way that we use to test the multiplexer during development. You could try it just using a USB cable connected to a PC. No need to power with 12V. Following is a description.

Set baud rate of P5 to 115200. Do not worry with AIS not working with that rate. The purpose is to see what happens when you press the SET button with "also connect to external" set. When you change anything in the settings, when the multiplexer starts, when you press reset, etc, the multiplexer sends text messages that show what the multiplexer does. This includes what it reads from EEPROM, what the user has requested, if the multiplexer creates or not it's AP, if the multiplexer is able to connect to an external multiplexer and so on. So, all you need is to run a serial monitor set to 115200 and look to the COM port that the PC attributes to the USB connection. I have not my PC in front of me. If I had I could send you a text file with an example of this information. If there is any anomaly in the connection to your external network, I think we could detect it using this feature.

Note that what really confuses me is - P5 works fine in AP only and P5 does not work when you connect to your router. As I can not envisage any problem on P5 (its functions are performed by the internal hardware of the microprocessor and not by the software that we wrote for the multiplexer) I am inclined that the cause could be related to the connection to the router. I know that you get the UDP data and my suspicion could be totally wrong, but, even so, it is not difficult to test what I just described.

Regards, Luis

[dagnall]

Paul,
Thanks, Just to add my apology for not responding faster!
The Pico scope is a very nice product and the serial decode may be a feature Luis had missed! I have serial decode on my 4 ch lab scope but my USB scom DS1M12 is now well over 20 years old and never has Serial decode! That new one looks excellent value!

I am glad that the AIS did pass the DSC DSE data. (at least when it was working!).

If you can see data on the output disappearing or being corrupt with the 'scope, that would go a long way to helping us find a root cause.

I have been trying to replicate the data loss here, but without success so far. There are two possible causes I can conceive for the device working in AP mode but not "connect to EXT">

• One is that the serial INPUT is somehow disabled/disrupted.
• The second is that the Serial Output is disabled/disrupted.

Did you notice if the "Input" LEDS showing the GPS activity stopped flashing when you connected to "EXT"? This might help locate this particularly well hidden bug!! (assuming its a bug!). I presume - but may be wrong?- that the serial input from the VHF only every flashed very occasionally? - or was there regular traffic from the VHF?

This issue has "got under my skin" a bit! And we would very much like to find a cause and fix it!

PS.. I have an AIT250 AIS - not same as yours I know.. But it was returned by a good friend to Digital Yacht as it never sent data out. They returned it as unrepairable, and he gave it to me to use as a AIS receiver. Long story short: I opened it up to look and found that it had two identical sockets internally. One for GPS antenna, one for VHF. They were swapped internally. I unswapped and have been using it (actively) ever since. But it did not reflect well on their service department!.

[Athertop]

Chaps, I took delivery of a new em-trak b954 AIS yesterday and installed it in my boat (raymarine would not repair my old one, only wanted to sell me a new one). I instantly had a load of new issues that I had never seen on my old raymarine ais (chart plotter was reporting AIS lost errors after a few mins and I would see the satellite count disappear in the proAIS2 software at the same time). With careful sequence of elimination steps (lots of rewiring, starting from minimal connections and adding slowly testing after each step) we think we found the cause of the issue (I say 'we', as most of the good ideas came from my very knowledgeable friend). It seems that the bi-directional 0183 connection from the e80 chart plotter to the AIS was seeing a data loop because of some very strange AIS multiplexer functionality. e80 data would be sent to the ais on its port1 sending pair and then would immediately receive the same sentences back from the AIS on its port1 receiving pair. As a result, the e80 and ais were getting overwhelmed with data going back and forth. Reading the em-trak ais manual, it does not document this as a function of its internal multiplexer (it only says that it resends bidirectional between its port1 and port2), so seems very odd it would send received data back out on the same port it received it on, but this certainly seems to be what we were witnessing. I have no idea if the original raymarine AIS was doing the same thing. To remove the issue, we simply removed the sending pair from the e80 to the AIS (as it turns out we didn't need these anyway), and all the issues went away. The original diagram on my first post here shows these connections. Also, the NMEA4WiFi now works perfectly as a result of these changes - even with station mode enabled and connected to my router.

I have a favour to ask, Luis. I believe that my new ais supports transmission of true heading data. To facilitate this, it needs to be sent NMEA0183 HDT sentences. At present there are only HDG sentences being derived from the Seatalk data input to the multiplexer. I am wondering therefore if you would be willing to amend the code to provide an option to enable the generation of HDT sentences to output P5 (without me having to enable Seatalk to P5 routing which would create a data loop). This could be calculated from the values in the HDG sentences (magnetic heading, magnetic deviation and variation).

Also, the multiplexer filtering reports an error when trying to add NMEA sentences DSC, DSE to the filter. May these please be included in the filter options?

Many thanks once again for your continued help with this. Paul

[Luis Sa]

Hello Paul,

Good to hear! And thanks to report it to us! Let me tell you that me and Dagnall have been working to optimize even further the internal operation of the NMEA4WIFi multiplexer and we will possibly upload a new firmware in the next days.

In regard to adding the 2 sentences to the Filters, we for certainly will include them in the above referred to firmware. In regard to the HDG and HDT sentences, I will ask Dagnall to have a look.

Regards, Luis

[Athertop]

That's great news, thanks Luis.

[Luis Sa]

Hello Paul,

I need to discuss the Heading Sentences with Dagnall. I answered too fast without noting to the requirement that you would not like to setup ST>P5. You should note that this is a very customised requirement and that could only be made once and not supported on future updates. I suggest we discuss this privately.

Regards, Luis

[dagnall]

I am wondering therefore if you would be willing to amend the code to provide an option to enable the generation of HDT sentences to output P5 (without me having to enable Seatalk to P5 routing which would create a data loop). This could be calculated from the values in the HDG sentences (magnetic heading, magnetic deviation and variation).

Also, the multiplexer filtering reports an error when trying to add NMEA sentences DSC, DSE to the filter. May these please be included in the filter options?

Many thanks once again for your continued help with this. Paul

Paul.
Hi,
I cannot easily arrange to send partial data from SeaTalk (assuming P4 is connected to SeaTalk and set to SeaTalk) without some major heart surgery! Also, in my experience, the heading true and deviation data tends to come from ROM inside the GPS chip that may not be properly updated. It is not sent AFAIK from the satellites.
The chip I am using right now on my bench for tests for example has null data in that field.
Many apps and programs allow you to enter a known variation for your region to convert Mag to True.

If the mag compass variation data is available on SeaTalk (SeaTalk message 99), then the existing Seatalk "compass heading" (84) should output a HDG and not HDM. - That should be automatic. You can see the seatalk data by using "debug mode " when you should see something like this: (I do not have a compass here so no ST=84 message!!)

Code: Select all

P#4: ST=99 00 00
     DATA STORED
     ... Mag Var 0 (0.0,W)  ...
P#4: ST=56 A1 01 13
     DATA STORED
     ... GPS date (011019) stored ...
P#4: ST=00 02 00 84 00
     $SDDBT,13.20,f,4.02,M,,F*1E
     ... Depth below transducer 13.20 Feet ...
P#4: ST=20 01 00 00
     $VWVHW,,,,,0.0,N,,*28
     ... Speed through water [0.0 kts] ...

If you are getting HDM, variation is either invalid or missing.

If you get the HDG, you might be able to do some filtering on P4 (seatalk) to just accept that message only and send ?

Sorry that was not particularly helpful. -- but we have added DSC and DSE (among many other small updates).

Dagnall

[Athertop]

Dagnall,

I only get HDG, and never HDT. I suggested the need to have HDT generated in the nmea01834wifi mux as I believe the AIS will use HDT (if it is present) to include true heading info in the AIS transmissions - it does not appear to want to use HDG to generate the true heading info itself. Its a bit of a guess on our part though that the AIS supports true heading transmission, as the AIS manual doesn't explicitly state this, but it does mention HDT in a table discussing 0183 to 2k conversion - so its a bit of an assumption that may lead nowhere.

Can I please ask if its possible to filter AIVDO and AIVDM sentences? This question is coming from my friend who has been helping me get this all working, and I am not entirely sure of the context, but thought I'd ask anyway.

Thanks, Paul

[dagnall]

Paul.
Sorry. I thought I had replied yesterday, but something got "stuck or lost"!

VDO and VDM can be filtered..
Just use a filter e.g. "0-A-VDO" to accept (only) VDO messages.
or "1-A-VDO-VDM" to accept VDO and VDM and to enforce checksum checking.
(or "0-R-VDM" if you wish to reject VDM, and everything else will be sent (without checking checksums.))

Have you tried using the GPS data (RMC) ? it will show you the boat track, which will be true.

With regard to N2K, N2k has a specific field that specifies if the heading data comes from a "true" reference, such as a gyro compass. In this case the "correct" N2K to NMEA conversion is HDT. This may be the source of the confusion?

[Athertop]

Gents,
Now that we believe true heading is not supported by the ais, this will be the new wiring scheme I plan to adopt. It makes things simpler by no longer relying on the AIS's integrated multiplexer.

Look OK?

Edit: I have included a better image of the solution. I had talks with em-trak who advised that the ais does transmit true heading if it was to receive HDT sentences. I am now trying to figure a solution to get HDT into the AIS.