Intro:

Many boats have an autopilot with an electronic compass, which serves HDG values. Not so common are heel and pitch. As heel (roll) is needed to calculate leeway it is a must have on a boat to get more control to trim of sails for more performance sailing.

The BNO055:

it is certainly a great fusion sensor for many applications, but I am not sure if it is realy a good sensor for navigation.
The big disadvantage is, that the sensor should keep on moving to self-calibrate. If the sensor is just turned on without any movement you do not get relieable values for HDG. Heel and pitch is not that susceptible to external disturbances therefore the values are more trusted, even with less movements of the sensor.

The BNO055 and KBox:

Personally I am not sure, if the sensor is as good in upright mounting position as it is laying.
The data sheets do not give any information for upright remapping of the axis.
(The sensors inside the BNO055 have some orientation of course and have different sensibility to z and x/y axis. If this is compensated in fusion mode? I do not know. We probably should contact Bosch in that matter.)

Placement of BNO055

(added 3.1.2018)
Forum discussion about Placement of BNO055 for vertical placement:

Beware that the BNO055's Euler output is incorrect at moderate to steep pitch and roll orientations. If you plan to tilt the sensor more than about 20 degrees, I recommend using the quaternion output instead.

https://forums.adafruit.com/viewtopic.php?f=25&t=108290&p=541754#p541754

Quaternions vs. Euler Angles

FAQs on Adafruit says:

According to Bosch BNO055 Euler angle output should only be used for eCompass, where pitch and roll stay below 45 degrees.
For absolute orientation, quaternions should always be used, and they can be converted to Euler angles at the last moment via the .toEuler() helper function in quaternion.h

https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/faqs
https://www.allaboutcircuits.com/projects/bosch-absolute-orientation-sensor-bno055/

Image (c) BOSCH from the Quick Guide

The other point is, that the sensor should be calibrated after each power on!

Some users mentioned this on forums and I discovered the same, that the sensor sometimes is switching +/- 180 degrees!
May be it has something to do with the fusion mode itself and the (probably) built in Kalman filter which is "running away" if the sensor is not calibrated (moved) after power on.

System Calibration

(added on 2.1.2018)
As long as the sysCalibration = 0 the BNO055 did not find magnetic north. After finding north the value might jump to magnetic north.
Therefore the code is extended that sysCalibration value must be > 0 for all value readings.
https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/device-calibration

The BNO has no internal EEPROM, so values must be stored to teensy's EEPROM.
Adafruit believes that the calibration can be restored, but there is strong evidence in the net, that this is wrong!
When the sensor is moved (turned) when in the no-power state, than the stored calibration values can not be ok.

KBox software side:

In the quick start is mentioned, that calibration of 2 is still quite ok and calibration value 1 should be signaled to the user, that the sensor should be calibrated again (e.g. by the figure 8 movement for heading).

• I think, we should separate the two measurement outputs HDG and heel/pitch to their own calibration values.
• And we should display the cal-values on the IMU-Monitor-Page too.
• So we can output at least heel and pitch (trim) with trusted values, even when HDG has gone. (As it stops output if cal-value is < 3 anyway)
• I would like to "invent" a just internal used Signal K JSON for the IMU sensor cals (e.g. SKPathKboxImuSensorMagCal / kbox.imuSensor.magCal....), which we could send to the Hub. So we could do the sensor check for the display (display HDG in red as warning etc.) completely separate of check for building the NMEA0183 and NMEA2000 sentence which should not go out if cal < 2 or 3.

Sources:

Quick Start Guide: https://ae-bst.resource.bosch.com/media/_tech/media/application_notes/BST-BNO055-AN007-00_Quick_Start_Guide.pdf
Calibration: https://www.youtube.com/watch?v=Bw0WuAyGsnY
Datasheet: https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST_BNO055_DS000_14.pdf
Adafruit: https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/overview

It would be very interesting to get feedback from other users in this matter, especially on HDG-datas. May be the movement of a boat is always big enough to keep the BNO055 well calibrated!

PGN 127250, 127251 and 127257 based on IMU data are respectively Magnetic heading, Rate of turn and Attitude.

See https://github.com/sarfata/kbox-firmware/wiki/Supported-PGNs

• 127250 and 127251 are supported by NMEA2000
• 127257 is not yet supported (see ttlappalainen/NMEA2000#10)

You write:
Two NMEA0183 outputs

How to activate NMEA0183 output?

We just need to implement SKVisitor::visitSKEnviromentOutsidePressure() in https://github.com/sarfata/kbox-firmware/blob/develop/src/common/signalk/SKNMEA2000Visitor.cpp.

Sometimes when reading lots of data from the IMU, the firmware gets stuck in a i2c_t3 loop. We need to investigate this and figure out what is going on.

This used to happen with the host firmware but does not happen anymore. Not really sure why and that is not a great sign...

Users should be able to configure the speed of NMEA ports without recompiling the firmware.

Instead of using the current "proprietary" log format, we should log data in SignalK update format. The logfile will be made of multiple independent JSON messages.

• Define the format more precisely
• Implement the new logger that uses SignalK
• Get time from the GPS messages received via NMEA0183 and implement "system time" (so that we know what time it really is when logging messages)
• Convert NMEA GPS messages to SignalK
• Convert Battery monitoring messages to SignalK
• Convert IMU messages to SignalK
• Convert NMEA2000 Speed and Depth messages to SignalK
• Convert NMEA2000 Wind messages to SignalK

See Ron's work here:
https://github.com/sarfata/kbox-firmware/pull/61/files#diff-e1a852b1882fac49cb1e32e9192d85e1R70

And @ronzeiller work here:
https://github.com/ronzeiller/kbox-firmware-teensy36/blob/master/src/common/signalk/SKNMEAVisitor.cpp#L60

Official doc on what OpenCPN supports: https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:opencpn_user_manual:advanced_features:nmea_sentences

We will get a lot of different settings. Some of them to change during operation, some to configure KBox before booting.

We discussed the ini-file vs. JSON earlier.

The aim will be a web based configuration one day.
But in the meantime we could start to put setting variables (where needed) all over the code.

Du you think it is possible to start with the ini-file type?
The JASON type for default settings and changing by web interface could then still be made. This would not touch the global names of the variables.

I think it is also a question of „keeping it simple“ vs. strict OOP with a huge amount of get and set....

Hardware configuration (mainly which service should run) could be made centrally with simple #include and commenting out if a task is not needed.

Just to add to the wiki:
you wrote: "Barometric pressure, temperature and humidity all ok on Raymarine i70 display. The display does not support "inside temperature"
This is true, but also i70 does not support "inside humidity". Is is the same as with temperature, only "outside humidity" is supported.

Suggested by Andreas Heertsch

It would be fine, if KBox has a logging-function for the accumulated distances the boat has driven. KBox would be the best place, to accumulate (and backup this value on SD-card), because KBox is always running. (If I use an old Smartphone for logging, I am afraid, that miles are lost, if the Smartphone is in "bad mood").

We should be able to download log files via WiFi, without having to open KBox and grab the SDCard.

Hi @sarfata! I have some notes for the wiki to get the kbox up and running with signalk-server-node. Please find them enclosed.

kbox-signalk-setup-doc_wiki_2017-08-20.txt

This is something Ron did on his KBox fork.

Multiple users have requested that KBox should relay available data to its serial ports.

I am thinking of the following:

• NMEA1 - Send everything we have at 38400
• NMEA2 - Send only GPS data at 4800

Data would be generated from internal SignalK data. This means anything coming from one of the NMEA port, the NMEA2000 or WiFi connection would be repeated as long as KBox understands it and knows how to translate it to NMEA.

This test is wrong:
https://github.com/sarfata/kbox-firmware/blob/develop/src/test/signalk/SKNMEAParserTest.cpp#L47

See http://www.catb.org/gpsd/NMEA.html#_nmea_encoding_conventions:

Where a numeric latitude or longitude is given, the two digits immediately to the left of the decimal point are whole minutes, to the right are decimals of minutes, and the remaining digits to the left of the whole minutes are whole degrees.

Eg. 4533.35 is 45 degrees and 33.35 minutes. ".35" of a minute is exactly 21 seconds.

Eg. 16708.033 is 167 degrees and 8.033 minutes. ".033" of a minute is about 2 seconds.

We need to fix the tests and the code.

OpenCPN doc says:

We should be publishing in Bars, which should work but Ron had to make a change to get this to work:
https://github.com/sarfata/kbox-firmware/pull/61/files#diff-e1a852b1882fac49cb1e32e9192d85e1R57

The $GPGGA sentence is "Discarding incomplete sequence"

I think it should be:
#define MAX_NMEA_SENTENCE_LENGTH 83

in NMEAService.h
Defined by the NMEA Standard is 82 plus 1 needed for termination of string?

Hi @sarfata ! It seems the kbox stopped to forward its internal data, temperature, fake humidity, barometric pressure... Any idea how it could have happened? I am running the dev branch.

Everything else looks correctly forwarded.

Please find enclosed some output from the kbox.

kbox_logs_2017-08-20.txt.zip

The version of the esp-tool embedded in platformio does not work with our program-esp firmware. This is probably a timing issue, but needs to be debugged.

The work-around is to use another esp programmer, as demonstrated in the Makefile but that only works on Linux and Mac OS.

See discussion on mailing list:

I was able to reproduce the problem with a Raspberry Pi at home tonight and I have found a fix.

The problem is that the raspberry pi echoes back some USB packets back to KBox which other serial drivers do not do (apparently this is specific to raspberry pi). Because KBox was not reading the input, the serial port was getting stuck. Just reading and discarding incoming data fixes this.
For more details, you can read this message on the teensy forum: https://forum.pjrc.com/threads/23770-Teensy-3-0-goes-mute-when-sending-to-Raspberry-Pi?p=32304&viewfull=1#post32304

The solution is very simple, just add the following lines in the loop() function of your src/host/main.cpp file:

while (Serial.read() > 0 ) {}

This is apparently a IANA assigned port for NMEA0183

• Create a new service to manage hall speed sensors and configure it to trigger at a given frequency (1Hz, 10Hz, 25Hz)
• Use one of the logic input on the teensy to count the number of pulses per interval of time
• Make the distance per number of tick configurable
• Generate "boat speed" message in signalk
• Generate NMEA2000 boat speed PGN from the signalk messages
• Use a logic analyzer and a pin to measure the jitter of the service and verify that it's reasonable
• Generate Log message with distance of current trip

For openCPN or similar we need the NMEA2000 converted to NMEA0183.
Signal K is internally used for all values

The questions are:

1. What to do if incoming values will be calculated due to calibration (tables) and/or offset?
   We need variables for that, as Signal K is limited

2. What to do if we need two different Signal K values for one NMEA0183 sentence?
   E.g. VWR – Relative Wind Speed and Angle sentence
   Signal K has no combined value for that.

Therefore we have a problem doing things like:
void SKNMEAVisitor::visitSKEnvironmentWindAngleTrue(.......)
for building the VWR sentence in SKNMEAVisitor.cpp where we also need Wind Speed.

IMHO NMEA2000, Signal K, NMEA0183, SeaSmart and so on are incoming and outgoing data formats which should not used for internally storing datas as the formats do not fit together.

In other words:
Signal K is not needed at all if someone just wants KBox for NMEA2000 -> NMEA0183 (openCPN and similar)
or wants KBox for NMEA2000 -> Actisense format for Expedition (instead an Actisense NGT-1)
You know, that KBox is mentioned on the Expedition Homepage? 👍
Personally I liked your KMessage much more as it gave me much more flexibility 😞

Use-case

• Have a navigation software (OpenCPN, iNavX, etc) send navigation NMEA sentences to KBox
• Data should be relayed to NMEA outputs and to NMEA2000 network

NMEA0183 Sentences to support

iNavX documentation says:

When a waypoint is active, the NMEA data sentences $GPAPB, $GPBOD, $GPBWC, $GPGGA, $GPRMB, $GPRMC, $GPXTE, $GPVTG will be sent to the TCP/IP host. "True/Mag" selection will set whether bearings sent in the $GPAPB NMEA sentence to the Autopilot are True or Magnetic.
Transfer: Will send waypoints using NMEA data sentence $GPWPL to the TCP/IP host.

• APB - Autopilot sentence
• BOD - Bearing waypoint to waypoint
• BWC - Bearing and distance to waypoint
• RMB - Like RMC but with info on destination waypoint.
• XTE - Cross track error
• VTG - Track made good and ground speed
• WPL - Waypoint info

Conversion to NMEA2000

TBD.

(see #6 for initial implementation of IMU data)

We need to make basic configuration much easier but it will be configured in a header file and will require recompiling the firmware.

• Speed of NMEA1 and NMEA2
• Orientation of KBox in the boat
• Enable / Disable IMU

Right now the SKNMEAVisitor and SKNMEA2000Visitor use a lot of dynamic memory to generate messages. This is not a great solution. We should try to use as little dynamic memory as possible.

Thomas,
I was trying now for hours to find out why the voltage reading in "my T36" KBox is not working, but without result.

The strange thing is, I do not see any difference between master-branch and develop-branch.
In master-branch it is working and in develop I get 0.0V

We use a lot of dynamic memory to create the SKUpdate object when parsing NMEA and NMEA2000 data (in the parsers). We should avoid this as it will create memory fragmentation and one day will fail catastrophically because we are out of memory.

This is an extremely useful feature for users who have NMEA0183 GPS and some NMEA2000 displays.

• There should be no logs sent via USB
• All NMEA and NMEA2000 messages that are normally sent via WiFi should be sent to USB port

So that users can look at it in realtime and make sure everything is working well.

The IMU should show:

• Current pitch
• Current yaw
• Current roll
• Current magnetic course

At the moment we have a lot of different KMessage Types, KSignal-Strings, Visitors with LinkedLists, and so on.

Would't it be nice to have something like global variables or a class just for actual boat Datas for Apparent Wind (Angle, Speed, Direction), True Wind (Angle, Speed, Direction), Depth, COG, SOG, Heel and so on which we can write to and get the most actual data where- and whenever we need them?

May be as a (basic, central) library so users could extend the class in some kind of plugIn to whatsoever they need? (Similar as openCPN....)

KBox Firmware could become an even more flexible framework for doing a lot of interesting things on a boat.
E.g. most of that is already possible by the hardware: http://www.yachtd.com/products/
But also thinking of future displays getting datas by Bluetooth (similar to Tacktick) or KBox doing things like B&Gs Hydra or Sailmon does and so on....

PGN 128259 Boat speed

see discussion with Timo: ttlappalainen/NMEA2000#84
IMHO we should not store ground speed there, as it will probably not coming and some microseconds later we get ground speed by GPS.

PGN 126992 System Time Date UTC

I do not know how to make an entry in signalk.json for Signal K fields

127250 Vessel Heading

Official NMEA2000 doc says:
Heading sensor value with a flag for True or Magnetic. If the sensor value is Magnetic, the deviation field can be used to produce
a Magnetic heading, and the variation field can be used to correct the Magnetic heading to produce a True heading.

So we could calculate True heading for output if values for variation AND deviation are there.

Attitude

Would like to add Attitude to SKNMEA2000Parser, to switch from internal sensor to boats values for heel and/or pitch.
Selectable by config setting.
Ditto for Magnetic Heading, if it is on the N2k-bus than I would rather like to switch to this source.
OK for you?

Config setting needed for

Seasmart Output vs. NMEA0183 Output
As we soon have a lot of NMEA0183 sentences for navigation
Each NMEA sentence should have its own config-selector for en-/disable

Hi Thomas,

Datas are coming over WiFi and all is working nice for a while.
No it says "Connection closed by foreign host."

Sometimes early, just now after 2 hours.

Did you experience similiar?
Any suggestions to make the webserver more stable?

Thanks,
Best Regards
Ronnie

in the NMEA2000Task.cpp seems to be a bug, as there is sent degrees to form N2k-Sentences.

Shouldnt be there a DegToRad as:

SetN2kAttitude(n2kmessage, _imuSequence, DegToRad( m.getYaw() ), DegToRad( m.getPitch() ), DegToRad( m.getRoll() ) );
    sendN2kMessage(n2kmessage);

    double magneticVariation = N2kDoubleNA;
    double magneticDeviation = N2kDoubleNA;

    SetN2kMagneticHeading(n2kmessage, _imuSequence, DegToRad( m.getCourse() ), magneticDeviation, magneticVariation);

Tested with Actisense NGT-1 and NMEA Reader shows correct values then.

See work by @ronzeiller here:
https://github.com/ronzeiller/kbox-firmware-teensy36/commit/e5ba6a3ce79cb01102524898e0d53f846a6e21e7

So that AIS data appears on NMEA2000 connected displays.

Hi Thomas
perhaps a very beginer question: I changed NMEA port 1 to 4800Bd and integrated KBox WiFi into my network.
Then I compiled and uploaded the firmware. All runs fine, but after Reset KBox shows only the testsuite.
Do I have to push some button?
Thank you
Andreas

It seems one of my NMEA 2000 device crashes the kbox. I am going to try to isolate the device to provide you more information.

Any idea how to troubleshoot it? I am running the development branch right now.

Here are the logs from the serial console.

WD main.cpp:90 Still running ... 0 connected clients - 36560 heap - IP: 0.0.0.0
WD main.cpp:90 Still running ... 0 connected clients - 36560 heap - IP: 0.0.0.0
D NMEA2000Service.cpp:92 Sending message on n2k bus - pgn=127508 prio=6 src=22 dst=255 len=8 result=success
D NMEA2000Service.cpp:95 TX: $PCDIN,01F214,00000000,16,000000FF7FFFFF01*57
D NMEA2000Service.cpp:92 Sending message on n2k bus - pgn=127508 prio=6 src=22 dst=255 len=8 result=success
D NMEA2000Service.cpp:95 TX: $PCDIN,01F214,00000000,16,010100FF7FFFFF01*57
D NMEA2000Service.cpp:92 Sending message on n2k bus - pgn=127508 prio=6 src=22 dst=255 len=8 result=success
D NMEA2000Service.cpp:95 TX: $PCDIN,01F214,00000000,16,FF0000FF7FFFFF01*57
D NMEA2000Service.cpp:92 Sending message on n2k bus - pgn=127508 prio=6 src=22 dst=255 len=8 result=success
D NMEA2000Service.cpp:95 TX: $PCDIN,01F214,00000000,16,FF4505FF7FFFFF01*53
D NMEA2000Service.cpp:37 Received N2K Message with pgn: 60928

Most users will never need to recalibrate accel/gyro but we should have a way to re-start the magnetic calibration once KBox is installed in the boat.