OpenMarine

I've used openplotter successfully on my sailboat for the last three years.  Every spring, I find time to upgrade the system to another set of sensors.  At installation, I just had GPS, depth, and boat speed.  That next spring I added wind and an autopilot, all NMEA 0183. Last year I bought an AIS transponder and upgraded engine settings to NMEA2000, interfacing these to openplotter and SignalK.  Finally, this year I decided to build a satellite box with some SparkFun boards coupled over QWIIC cables (no soldering!) to an ESP32 development board to add these sensors:

• IMU for pitch/roll/yaw    (SparkFun BNO080 board)
  
• GNSS dual antenna true heading  (Two SparkFun ZED-F9P boards)
  
• House and starter battery volts, house current (ESP32 board with ADCs)
  
• Outside temperature, barometric pressure, and humidity (SparkFun BME280 board)
  
• Ice box temperature  (1-wire temperature probe)
  

The only soldering I had to do was to add one wire from the uBlox ZED-F9P PPS (pulse-per-second) to an ESP GPIO interrupt, so that the outputs are created at each PPS.  Because the satellite box is close to the instrument panel (and the installed RPI), I thought it would be simple just to stream SignalK native format out the FTDI serial port of the ESP board, and specify this as an openplotter serial device.  

But there are no input characters seen at the Pi.  I'm mystified as to what could be the issue.  Here's a few deltas that are broadcast every second, and captured on a Windows PC using Terra Term:

{"updates":[{"values":[{"path":"navigation.position","longitude":47.58951,"latitude":-122.2933,"altitude":43.323}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"navigation.speedOverGround","value":0.568}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"navigation.courseOverGroundTrue","value":3.838401}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"navigation.headingTrue","value":3.838401}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"navigation.gnss.baseline","value":39}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"navigation.attitude","roll":0.270219,"pitch":0.047778,"yaw":0.04926}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"navigation.gnss.methodQuality","value":1}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"navigation.gnss.satellites","value":18}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"navigation.gnss.positionDilution","value":1.49}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"navigation.gnss.geoidalSeparation","value":-18.81}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"electrical.batteries.house.voltage","value":0.003713}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"electrical.batteries.starter.voltage","value":0.004341}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"electrical.batteries.house.current","value":1.347656}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"environment.outside.pressure","value":101994.7}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"environment.outside.temperature","value":305.09}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"environment.outside.humidity","value":23.3457}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}
{"updates":[{"values":[{"path":"environment.inside.temperature","value":292}],"source":"Aux","timestamp":"2021-03-29T20:50:29.250Z"}]}

Moving the USB cable over to the PI, the cable is correctly detected:

pi@openplotter:~ $ lsusb
Bus 001 Device 006: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 001 Device 004: ID ffff:f8ff  
Bus 001 Device 005: ID 0461:0022 Primax Electronics, Ltd 
Bus 001 Device 007: ID 0424:7800 Standard Microsystems Corp. 
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

But nothing is streamed, as per:

pi@openplotter:~ $ stty -F /dev/ttyUSB0 115200
pi@openplotter:~ $ cat /dev/ttyUSB0
^C

After disconnecting the USB from the Pi, and reconnecting, a tail of the system log indicates:

pi@openplotter:~ $ tail -20 /var/log/syslog
Mar 29 12:34:34 openplotter dhcpcd[480]: wlan0: no IPv6 Routers available
Mar 29 12:34:35 openplotter systemd[1]: systemd-fsckd.service: Succeeded.
Mar 29 12:34:47 openplotter systemd-timesyncd[354]: Synchronized to time server for the first time 212.18.3.19:123 (2.debian.pool.ntp.org).
Mar 29 12:34:56 openplotter systemd[1]: systemd-hostnamed.service: Succeeded.
Mar 29 12:36:46 openplotter kernel: [  158.710109] usb 1-1.3: USB disconnect, device number 6
Mar 29 12:36:46 openplotter kernel: [  158.711401] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Mar 29 12:36:46 openplotter kernel: [  158.711543] ftdi_sio 1-1.3:1.0: device disconnected
Mar 29 12:37:10 openplotter kernel: [  183.578341] usb 1-1.3: new full-speed USB device number 8 using dwc_otg
Mar 29 12:37:11 openplotter kernel: [  183.736026] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
Mar 29 12:37:11 openplotter kernel: [  183.736050] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 29 12:37:11 openplotter kernel: [  183.736067] usb 1-1.3: Product: FT231X USB UART
Mar 29 12:37:11 openplotter kernel: [  183.736083] usb 1-1.3: Manufacturer: FTDI
Mar 29 12:37:11 openplotter kernel: [  183.736098] usb 1-1.3: SerialNumber: DN05JGRC
Mar 29 12:37:11 openplotter kernel: [  183.744590] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
Mar 29 12:37:11 openplotter kernel: [  183.744851] usb 1-1.3: Detected FT-X
Mar 29 12:37:11 openplotter kernel: [  183.749434] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0
Mar 29 12:37:11 openplotter mtp-probe: checking bus 1, device 8: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3"
Mar 29 12:37:11 openplotter mtp-probe: bus: 1, device: 8 was not an MTP device
Mar 29 12:37:11 openplotter mtp-probe: checking bus 1, device 8: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3"
Mar 29 12:37:11 openplotter mtp-probe: bus: 1, device: 8 was not an MTP device
pi@openplotter:~ $ 

I'm not that familiar with Linux, does anyone have any suggestions as to how to debug this issue?  I've tried 3 of the 4 Pi USB bulkhead connectors, with the same result.

Jim

The server data fiddler didn't like your JSON, but if you remove >

Quote:,
     "source": "Aux",
     "timestamp": "2021-03-29T20:50:29.250Z"

from your deltas it goes through OK. Both these fields will be added by the server anyway.

PaddyB, thanks for spotting that. Although that was an issue, the main problem is that the ESP32 development board is configured as an Arduino, which must support a serial bootloader as well as standard run mode. For the RPI ttyUSB0 device, I had to write a utility that would toggle the RTS line while holding DTR low to force the board to run mode. For some reason, Windows must do this automatically when opening the COMx port, since the SK deltas happily streamed into TerraTerm without any RTS/DTR forcing.

With respect to the problem you pointed out, since my GNSS subsystem is now on this "Aux" device to the RPI, without timestamps being specified in the delta how does the PI ever get a time update? Normally my RPI boat computer is not connected to the internet, so it seems that without a GNSS timestamp, over time the RPI (and thus SK) will drift. I did play around with where to put "source" and "timestamp" in the JSON string, but couldn't get it to pass the data fiddler test.

How come there are no navigation.datetime delta messages, aux must be getting thedatetime from somewhere?

this page says the consumer should be adding the timestamp >
http://signalk.org/2014/11/05/new-delta-format.html
"Paths are dot delimited and it is expected that the consumer propagates the source timestamp down all of these paths."

The server will fill in timestamp if it is not there and uses system time.

You can use set system time plugin to set it based on gps time navigation.datetime.