OpenMarine

I am using RP3 with OpenPlotter 2.0.1-beta and mpu92. It worked before upgrade. 

Detected IMU compass mpu9255

localhost:3000 ok

localhost:20220 connection in OpenCPN no response
Signal K Instrument no response 
Should I downgrade? How?

Boot log:
Checking OpenPlotter autostart... | enabled
Checking user "pi" password... | changed
Checking screensaver state... | enabled
Checking headless state... | disabled
Checking OpenPlotter packages source... | added
Checking Signal K server... | running
Checking I2C sensors... | I2C enabled | not running
Checking OpenCPN... | not running | autostart disabled
The default OpenCPN connection is missing and is not getting data from Signal K. Please create this connection in OpenCPN:
Network
Protocol: TCP
Address: localhost
Data Port: 10110
Checking My App dummy sensors... | not running
Checking Pypilot... | Only compass
Please enable a Signal K connection fot Pypilot Signal K data
Checking Moitessier HAT... | not attached | I2C enabled | SPI enabled
Moitessier HAT driver is not installed.
Checking serial connections alias... | All your serial connections have an assigned alias
Checking serial connections conflicts... | no conflicts
Checking network connections conflicts... | no conflicts
STARTUP FINISHED

Signal K - NMEA 0183 output (server)
TCP openplotter.local:10110
TCP 10.25.1.87:10110
OpenCPN connection (server)
UDP openplotter.local:20220
UDP 10.25.1.87:20220
Internal Pypilot Signal K server (server)
TCP openplotter.local:21311
TCP 10.25.1.87:21311
Pypilot Signal K output (client)
UDP openplotter.local:20220
UDP 10.25.1.87:20220

pypilot has input and output of nmea0183 on 20220. Maybe you tried to make a signalk connection in opencpn which is a very new feature and doesn't work with pypilot.

Tnx for quick response. I used the SD image with the OpenPlotter 2.0.2-beta. Since the NMEA didn’t work, I tried to change a few things. 


The only thing in Pypilot mentioned under “Connections” is Signal K:Heading, Heel, Pitch. -> Should I remove that and make a NMEA connection?


https://drive.google.com/file/d/1b-2ZSoQ...sp=sharing

In pypilot "only compas" mode you get signal k data in UDP localhost 20220. You have to create that connection in SK and use "signal k to NMEA 0183" plugin to get data in opencpn by TCP localhost 10110
In pypilot "autopilot" mode you get NMEA 0183 data in TCP localhost 20220. You have to create that connection in SK and you will get NMEA 0183 directly in opencpn by TCP localhost 10110.

Remember, remove any opencpn connection. You have to set just TCP localhost 10110 imput in Opencpn to get data from SK.

this will be easier when we have documentation

This is very confusing because there are multiple paths and conversions of data possible.

There is a pypilot plugin of openplotter which converts pypilot signalk into signalk node which can then be converted to nmea0183 available on tcp 10110. pypilot directly provides nmea0183 on port 20220 or assigned serial ports. So far output is only to tcp connections, but it might be useful to be able to assign particular serial ports to output certain nmea data, it just isn't supported or implemented yet.

Sean

(2020-01-07, 10:07 PM)seandepagnier Wrote: [ -> ]This is very confusing because there are multiple paths and conversions of data possible.

There is a pypilot plugin of openplotter which converts pypilot signalk into signalk node which can then be converted to nmea0183 available on tcp 10110.    pypilot directly provides nmea0183 on port 20220 or assigned serial ports.   So far output is only to tcp connections, but it might be useful to be able to assign particular serial ports to output certain nmea data, it just isn't supported or implemented yet.

Sean

Yes, it is a little bit confusing but I hope it will get easier with documentation.

Lot of people will use "the only compass" mode and we prefer to generate SK data for heading, pith and roll instead of NMEA 0183 because SK node server can not parse XDR sentences for pith and roll. We use UDP localhost 20220 for this. SK node server can convert pith and roll into NMEA 0183.

When using the "autopilot" mode, NMEA O183 data is generated for heading, pith and roll in TCP localhost 20220 but we need to keep UDP localhost 20220 only with pith and roll SK data to get these data into SK node server. This time conversion from SK to NMEA 0183 for pith and roll is not necessary.

I think I almost have this configured. I have in the http://localhost:3000/@signalk/instrumentpanel/  dashboard yaw, pitch, and roll data which  I know is from pypilot UDP set to autopilot

pi@openplotter:~ $ nc -u -l 20220
{"updates":[{"$source":"OpenPlotter.I2C.pypilot","values":[{"path": "navigation.attitude","value":{"roll":-0.005427974123,"pitch":-0.0029496065170000006,"yaw":null}}]}]}

I also can see NMEA0183 data on TCP port 20220

pi@openplotter:~ $ nc 127.0.0.1  20220
$APXDR,A,-0.179,D,PTCH*59
$APXDR,A,-0.291,D,ROLL*4E
$APHDM,270.337,M*31
$GPGSA,M,3,28,17,30,19,06,01,03,07,22,11,,,2.3,1.0,2.0*38

In the  SignalK interface http://localhost:3000/admin/#/dashboard under Server->Connections I added the UDP and the TCP connections

Input Type: NMEA0183
Enabled: yes
ID: pypilot-tcp
NMEA0183 Source: TCP Client
Host: localhost
port 10110

the same for the  UDP port

Input Type: Signal K
Enabled: yes
Logging: no
SignalK source: UDP
Port: 20220

and pressed apply. I then can see these connections

ID             Input Type   Enabled Logging
pypilot-tcp     NMEA0183    Yes        No
pypilot-udp     SignalK     Yes        No

Restarting SignalK. And I get the only the three metrics from UDP but no metrics for the NMEA data.  Running OpenPlotter "Check System", I still get:

"Please enable a Signal K connection for Pypilot NMEA 0183 data"

The SignalK plugin @signalk/signalk-to-nmea0183 is installed but I dont want to output NMEA just want NMEA metrics in SignalK. Above there is discussion about translating NMEA to Signal K, but I'm not following it if that is what needs to happen.

Any idea why yaw is null?

Am I the only one who thinks the signalk standard would be better:

instead, this:

$source could be left out in subsequent messages if unchanged

The current implementation is difficult to work with, too many rules to interpret so harder to re-implement, confusing to read, and wastes bandwidth because the messages are twice as long as they need to be. This only will increase lag especially on slow links and make data logging larger. Can we re-think this protocol now that use cases are more clear?

hmmm.. Pitch and roll are respective of gravity, how to you measure yaw rotation in respect to gravity? Would the compass heading be more useful? My test stand is sitting flat on a wooden stool and I can see that the compass heading change as I rotate the IMU.  Maybe if yaw was the compass angle then would not need the NMEA connection for heading.  

I agreed. The extra precision beyond a 1000th or even 100th of a degree in pitch or roll on a sailboat is meaningless, and just uses up bandwidth.

hmmm...
If Signal K could read serial NMEA, then it would not need to be fed from pypilot? I'll  try that...