ed209 wrote:

A quick update:
Happily I just got word from (Yacht Devices) that I should have a new YDEN-03 to test next week. In their words:
"the new model has a much more powerful CPU and a larger amount of memory and will easily handle your requirements."
I will post back here with test results.

Well, after spending WAAAAAAAYYY too long on this for a ~$400 device; here’s my findings about the YDEN03.

TL;DR: It's better and more deployable than the YDEN02, still has issues, but I'm hoping they can be fixed. 
I'm being put in touch directly with their engineers and will post back with updates as they happen. Might take a while.


First, the good...

1. The YDEN02 was prone to dropping existing connections, or starving one port to allow connections on another. This makes for very unpredictable behaviour, and is hard to test. YDEN03 no longer does this, but is still severely limited to a handful of connections in total. 

- It consistently serves 3 connections per TCP port, and handles sending UDP on the third. It never serves more than three per port, and you never get a situation where NMEA 2000 on 1457 robs NMEA 183 on 1456, which is definitely better.

- That’s still a problem in any situation where people want to connect on mobile devices and can’t use UDP. The bottom line is that dynamic connections to the YDEN will appear unreliable even if the YDEN itself is reliably serving its limit of three connections to a port.

- Why not only use UDP? One good reason is that you can’t receive UDP broadcasts on an iPhone unless the wifi network you are connected to is bridged to the Ethernet the YDEN is connected to. This is impossible over VPN/Zerotier/Tailscale connections so you have to use TCP.

- Notwithstanding, this limitation is as advertised, better then the YDEN02, and is something that can be lived with and planned around as long as the device operates deterministically and dependably.

2. Logged data download is much better than the weird mechanism of the YDEN02. You don’t have to sacrifice a port and reconfigure it just to get data off the device.

3. The software looks a bit better, is a bit more responsive, and you do get a couple of key new bits of information on the home page, most notably Ethernet TX/RX which is a step in the right direction.


Now, the bad...

4. BUG: There is some weirdness around authentication - sometimes login appears to have failed but if you refresh the page it works. Sometimes after rebooting the device you don’t have to authenticate to connect again, implying a cookie mechanism that isn’t secure. Screenshot attached of how it behaved out of the box, showing “Request error. See console". I think there’s some basic cookie problem going on, but this wasn’t a dealbreaker considering the other problems, so I spent no time on trying to reproduce this.

5. FEATURE: What is really needed is a page that shows what current connections exist for each TCP port, their IP addresses and source port numbers. Throw in some bytes in/out per connection for bonus points. You should be able to enable a monitor to see the data actually being received or sent to the NMEA bus (like Expedition’s raw data display per instrument).

6. FEATURE: There also should be a console log page so you can see what the system is experiencing when there are problems; this is standard on all network comms devices.

7. FEATURE: Ideally I’d like to be able to ssh to the command line of the device, for which there is no substitute when troubleshooting - it’s linux so that shouldn’t be a big deal.

8. FEATURE: And there should be ntp time sync so you can see when things happen.


And the ugly...

9. Unfortunately, YDEN03 is unreliable under load (or over time if not under load), and eventually/randomly completely locks up.

- I wrote a python script to hammer the device with many sockets concurrently and was able to reproduce the problem. I sent a report, some packet captures, and the sourcecode back to Yacht Devices engineering. Their engineering team should be able to diagnose the issue armed with this information, so I am still hopeful this can be fixed in a quick firmware upgrade.

- It’s probable that the YDEN02 device does this too; the nature of boats is that people turn the instruments off regularly, effectively rebooting the YDEN much more than a regular linux system, so it may be that dealers are seeing this problem less than would otherwise be the case. I would guess this manifests itself as “voodoo” that is very hard to diagnose. 

10. There’s a problem with the mDNS implementation which I did not test/notice on the YDEN02.

- If you change the hostname, the display name remains yden, which is problematic when you have more than one YDEN device. 

 

Last edited by ed209 (8/13/2025 2:47 am)

Hi,
Ever since I installed a YDEN-02 for my GNX displays, Expedition Marine boat tracking no longer sees any other boats.  My logs show I am receiving PGN 129038 and 129039, but only as individual 8-byte frames (“RAW” CANbus fragments). I never see full decoded position messages, only identification/MMSI—no latitude, longitude, COG, or SOG.

Is there a way to configure the device so that it outputs full AIS position reports (with all relevant fields, e.g. MMSI, latitude, longitude, COG, SOG, etc.) over UDP/TCP or is there a better replacement than can also work with GNX displays?  

Nick wrote:

CAN isn't designed for TCP.

The only solution I can think of is an Actisense NGX-ISO and a serial to ethernet adaptor such as a Moxa.

NMEA OneNet may be an option in the future, but given how many years NMEA 2000 took to become established ...

As Nick points out, using an industrial-grade device like a Moxa serial/terminal server is by far the most reliable solution.

Consumer-focused adapters such as Yacht Devices /Actisense’s wireless/Digital Yacht and many other "marine"  bridges tend to be unstable in real-world NMEA 2000 deployments.
The core limitation is processing headroom: these units are built on small embedded controllers with limited buffers.
Never mind the added latency.
Once N2K bus utilization climbs above ~25%, they begin to drop frames or introduce timing errors. Several manufacturers have acknowledged this behavior in correspondence — the devices simply run out of resources under moderate bus load. In my own experience, I ended up spending more on Yacht Devices / Actisense / Digital Yacht gear, only to find that none of them were “set-and-forget” solutions.

By contrast, the Moxa hardware is designed for industrial automation and critical infrastructure, where deterministic serial performance is non-negotiable. They cost a little more up front, but once configured they disappear into the background — you stop thinking about the bridge entirely.

For example, with the Moxa W2250:
One port is connected to a FOG sensor at 2 Mbit, the other to an NTG-1-ISO at 230 400 baud. Both run without a single RX/TX error or buffer overrun.
Port splitting works as advertised: multiple clients can subscribe to the same data stream without collisions or packet loss. This alone is crazy good. 

The FOG sensor receives RTK corrections for <2 cm positioning accuracy over the serial link without dropping a frame. Ironically, when I tested the same sensor via a direct 3 m serial cable, signal integrity was worse — right at the edge of what the physical layer supports.

The added bonus is operational simplicity: with the W2250, you can remove all physical cabling to a laptop or tablet and still maintain clean, deterministic serial links.
The industrial-class approach isn’t just more robust — it fundamentally avoids the architectural limitations of the lower-end adapters.

The FOG sensor is in one port (using its own protocol), on the other port I have an Actisense NTG-1-ISO (NMEA2k to Serial).
The reason I mentioned the fog sensor is because it highlights the Moxa Capabilities. 
The new Yacht Devices YDEN03, chokes at 230400 when the bus is at ~25%.
On the other hand the Moxa's CPU is at <11% when one port is using RS485 @2Mbps, and the other port RS232 @230400.
It also supports 8 clients per port with full Tx, from the client to the serial devices. In theory you could have 8 different apps sending NMEA2K into the bus.
I have Expedition and Adrena concurrently sending data to the N2K bus using the same Actisense NTG-1-ISO.
The Actisense shows as 2 different COM ports. The Moxa NPort driver orchestrates the Txs from both applications so they do not write over themselves. 
 

Last edited by Astolfo (9/10/2025 11:23 am)

sparky wrote:

Does the NTG-1 allow for full CAN bus utilisation?

Depending on what you mean for "full CAN" utilization? 
These are devices that bridge N2K, and have no say on how much you can load the bus. 
The NGX-1 ISO (newer NTG-1-ISO), can transmit at full 230400.
These devices can't remove the 30% load limitation on the N2K bus, which is a design flaw, not only on the protocol itself, but it is augmented by the nodes (devices, by the lack of processing and buffers ) in the bus.
The Moxa will not be the limiting factor.