I need to double check, but I think the reason that some data like depth is not coming out on TCP/UDP, is that we recognise the sentence but there is no checksum so we do not convert it and put it in to the Signal K namespace memory. Sentences that are recognised are converted in to our namespace memory and then the resulting Signal K data is converted back to NMEA0183 to be output via UDP or TCP.Īt first sight this might look a bit odd, but it means that as more and more conversions are added that we end up with one conversion engine that takes everything in, converts and stores everything in Signal K and then spits out whatever data formats are enabled. I need to check with my development team, but we only support some NMEA0183 sentences at the moment (list will grow over the winter) and any sentences that we do not recoginise, are sent through to the TCP or UDP ports if enabled.
Seaiq opencpn serial#
This is seen with SeaIQ and also NavMonPC data capture on TCP and SrialTools on the Serial port.Īs an aside, when will data from Input NMEA ports be available on NMEA Output ports? Just want to make use of Opto Isolators! However on the TCP output, only the following sentences are sent: Most critical to me is DBT (Depth Below Transponder) but hard to understand why not all NMEA passed on to TCP as advertised.
Several sentences are accepted and converted to NMEA data over TCP, but several sentences do not appear on TCP even though they are present on serial interface. Data is coming from a Nexus server over RS232 and input to NMEA2 of iKommunicate.
Some of the NMEA 0183 data from a serial RS232 input to iKommunicate NMEA in is not being output on TCP on ethernet.
0 kommentar(er)
