IMUMonitorPage added #89

ronzeiller · 2017-12-09T23:15:34Z

Hi Thomas,
started a new IMUMonitorPage PR as draft for discussion:

introduced a config file. The idea is to start config with something which will grow, also to get a collection and an overview. When there is a solution found later, ini-file, JSON or whatsoever it will be easy to change the setting variables already in use.
I do not know how to combine/extend IMUService and IMUMonitorPage to set/get cal variables.
friend class? Could you help here please?
The plan is to build in a filter for the display as discussed earlier into the Page. Is working already in an experimental version here.
For different mounting positions of KBox: I would like to start in the IMUService and not in the driver (as discussed earlier) because beside of axis and sign turning it will also be necessary to invert pitch or heel or transform angles, as done already in the Service.
I would like to start with our mounting positions (if somebody needs another, no problem). (Is already working here, I just wanted to pull something to discuss before the PR is too large....)
Last but not least I plan to write the calibration into the EEPROM and load it at start.
And I would like to introduce an offset into pitch and heel for zero-setting by a long button-press. Reading, writing and offset is working already. As soon I can get/set variables from the Page -> Service I can implement it.
For storing the cal-datas: I thought of first storing, if all calibration is 3 and then check every 10 minutes? What is your opinion?

The page is working already (without cal display and without filter)

coveralls · 2017-12-09T23:20:07Z

Coverage remained the same at 64.397% when pulling 14a7546 on ronzeiller:rz_imu-page into d20ad94 on sarfata:develop.

sarfata · 2017-12-10T03:40:16Z

src/host/services/IMUService.cpp

    update.setNavigationHeadingMagnetic(SKDegToRad(heading));
    _skHub.publish(update);
+  }
+
+	if (accelCalib >= cfHeelPitchMinCal && gyroCalib >= cfHeelPitchMinCal) {


I think there is a indentation issue here. Can you make sure your editor is configured to replace tabs with spaces?

Thanks, I was trying Netbeans as IDE because of it's internal versioning which I find great. Will have to take more care in configuring it.

sarfata · 2017-12-10T03:45:10Z

src/host/main.cpp

@@ -102,6 +104,11 @@ void setup() {

  BatteryMonitorPage *batPage = new BatteryMonitorPage(skHub);
  mfd.addPage(batPage);
+
+	#ifdef IMU_MONITOR_PAGE
+    IMUMonitorPage *imuPage = new IMUMonitorPage(skHub);


To allow IMUMonitorPage to have more access to IMUService, pass a reference to the IMUService when you create IMUMonitorPage:

IMUMonitorPage *imuPage = new IMUMonitorPage(skHub, *imuService);

And then in IMUService.h you can declare new functions for example:

public: void getLastValues(int &accelCalibration, double &pitch, double &heel, int &magCalibration, double &heading); void saveAccelCalibration(); void resetAccelCalibration(); void saveMagCalibration(); void resetMagCalibration();

(and anything else you need)

This way, the imuPage will have more access to imuService but we will keep the imu logic inside the imu service.

This is looks nice, but I do not know how to declare
IMUMonitorPage(SKHub& hub, IMUService* ims);
this gives me an error "redefinition of class IMUService"
how to do this right?

sarfata · 2017-12-10T03:46:43Z

lib/KBoxHardware/src/KBoxConfig.cpp

@@ -0,0 +1,52 @@
+/*


I don't think we should put this in KBoxHardware because this folder is only for hardware support. The config is very specific to what kbox does so I would just put this into src/common/config (so it can be shared with the wifi module too).

ok, done.
Just to keep in mind, that (as far as I know) if the config is in the src part then libraries can not access it, which means that we will have to do the axis- and sign thing in IMUService and not in the driver.
(I think for now it is perfect, and it could easily be changed later, if needed)

sarfata · 2017-12-10T03:48:30Z

lib/KBoxHardware/src/KBoxConfig.cpp

+//           Use of internal Sensors
+// ---------------------------------------------------------------------------
+// [sensors]
+bool cfUseHdgFromBusIfExists			= true;   // Get Heading from NMEA2000?


I think this should be a class with methods. To begin, we can just hardcode the values in the methods inside the .h file but in the future we can re-implement this class and read from JSON.

You mean to make them as private variables and implement a getXyZ() for all of them?

Could you propose the name of the class to stay within your naming concept?

sarfata · 2017-12-10T03:52:17Z

This implements #10

coveralls · 2017-12-11T00:35:44Z

Coverage decreased (-0.4%) to 67.732% when pulling d11d220 on ronzeiller:rz_imu-page into 1885005 on sarfata:master.

ronzeiller · 2017-12-11T01:10:49Z

Got rid of the redefinition error , but now I have the imuService.getLastValuesin the constructor of IMUMonitorPage and not in the
void IMUMonitorPage::updateReceived(const SKUpdate& up)

Could you please have a look at this?

Now the concept is: the values for the monitorPage are triggered by updateReceived(const SKUpdate& up)
which means the updates are coming by the interval of the imuService.
In the IMUPage would be the filter and a elapsed time thing for bringing down the values to display-frequeny.

Just thinking of: would it be better to make the display of data (at least the Voltage, Baro, IMU, may be wind and other pages) an interval task?
This would mean, that the filter would be in the IMUService (which would be there anyway if you might switch to a better IMU sensor for future KBox Hardware releases e.g. this one: https://www.adafruit.com/product/3463 which has no integrated fusion as the BNO055)
The other advantage of filtering in high frequency is to get out noise without visual time delay. (which we certainly have at low frequencies, you can see it quite a lot in openCPN!)

The Page loop would then just call an actual value for the display (completely independent from the Service-frequency.) Same for different other (low speed) outputs....

The other things:

config settings will change as discussed
two Service defines added.
The aim is, that users could define their services needed for a special hardware.
E.g. it would then be possible to comment out several services to make a logging device with a T3.2 or 3.6 + CAN without display, wifi, baro, imu
Or just to switch off Baro and IMU if not needed and so on....
Or with a special (less equipped and lower priced) KBox as N2k->NMEA0183 Serial/WiFi-converter.

Would you like this?

sarfata · 2017-12-11T05:40:33Z

Just thinking of: would it be better to make the display of data (at least the Voltage, Baro, IMU, may be wind and other pages) an interval task?
This would mean, that the filter would be in the IMUService (which would be there anyway if you might switch to a better IMU sensor for future KBox Hardware releases e.g. this one: https://www.adafruit.com/product/3463 which has no integrated fusion as the BNO055)
The other advantage of filtering in high frequency is to get out noise without visual time delay. (which we certainly have at low frequencies, you can see it quite a lot in openCPN!)

The Page loop would then just call an actual value for the display (completely independent from the Service-frequency.) Same for different other (low speed) outputs....

I think I agree but let me restate this to make sure we are on the same page:

IMUService should process data at high speed (ideally, as soon as it's available) and will apply the filtering and send the data to the SKHub
Rewriting IMUPage as a interval based task makes sense because you know data will always be available from our IMU and you need calibration data that is not included in SKUpdate.
- The only concern I have with this is that IMUPage will always only show value from KBox internal sensor, and not from another device on the network but that is completely fine in this case.
- The MFD task already takes care of redrawing the screen. You do not need (and should not) create a new interval service. Instead, override the processEvent(const TickEvent &e) method (from Page.h) to update the text fields every x ms.

Regarding config, let me put something together too so we can compare our approaches and it will be more explicit for me to write code than explain this in Github comments ;)

I want to arrive at a configuration system based on a file (INI or JSON) that reads configuration when KBox starts. I do not want users (or me ;) ) to have to re-compile just to change some basic options.

I understand why you have the #define but it forces us into a "build-time" setting. For pages and services this might be the right option. For other options, it will not be the right option. I think we should try to make things configurable at runtime first, and revert to build time if we are forced to for some reason.

For example, in the case of a KBox variant, I think the built time configuration is the only thing that makes sense but we can do it with a dedicated target and a build time -DKBOX_MINI_VARIANT.

sarfata · 2017-12-11T05:42:16Z

src/host/pages/IMUMonitorPage.h

+
+class IMUMonitorPage: public Page, public SKSubscriber {
+  private:
+    TextLayer *_hdgTL, *_heelTL, *_pitchTL, *_calTL;


Declare a new private reference here to keep the reference to the IMUService:

IMUService &_imuService;

Great! Worked fine!
Thank You,
update will come soon :-)

sarfata · 2017-12-11T05:43:27Z

src/host/pages/IMUMonitorPage.cpp

+#include "signalk/SKUnits.h"
+
+
+IMUMonitorPage::IMUMonitorPage(SKHub& hub, IMUService &imuService) {


You need to keep that reference to imuService so you can use it later.

Just change this line to:

IMUMonitorPage::IMUMonitorPage(SKHub& hub, IMUService &imuService) : _imuService(imuService) {

This means that when the class is initialized, it will store the reference in the private property _imuService (which we need to declare below).

sarfata · 2017-12-11T05:44:00Z

src/host/pages/IMUMonitorPage.cpp

+
+  hub.subscribe(this);
+
+  imuService.getLastValues(_accelCalibration, _pitch, _heel, _magCalibration, _heading);


We are saving it now so you can refresh this whenever you want. For example, in the method processEvent(const TickEvent &e);.

One of the advantage of using TickEvent is that this page will only display when it's on the screen. Not when it's hidden.

ronzeiller · 2017-12-11T10:46:08Z

I think I agree but let me restate this to make sure we are on the same page:

IMUService should process data at high speed (ideally, as soon as it's available) and will apply the filtering and send the data to the SKHub

Yes

The idea behind was, that any sensor software should deliver fine datas.
We have to make a difference of high speed data filtering for a specific sensor, which is in the sensorService.
And we have different outputs.
Where a display should make it's own (selectable) display filter/damping.
This is how it is made on every MFD on the boat. 1.)

The question for later on will be: how and where it will be done for a slow serial output......?

Rewriting IMUPage as a interval based task makes sense because you know data will always be available from our IMU and you need calibration data that is not included in SKUpdate.

If I understood it right, the display is based on the eventTicks, which is already an interval by processEvent(const TickEvent &e)

The only concern I have with this is that IMUPage will always only show value from KBox internal sensor, and not from another device on the network but that is completely fine in this case.

I think we could make this dependent of a config-setting
"take internal sensor for HDG" and "take internal sensor for heel/pitch" 2.)

Regarding config, let me put something together too so we can compare our approaches and it will be more explicit for me to write code than explain this in Github comments ;)

I want to arrive at a configuration system based on a file (INI or JSON) that reads configuration when KBox starts. I do not want users (or me ;) ) to have to re-compile just to change some basic options.

Yes, this was my intention too.
This sounds great, I will love to wait for your approaches!!

I understand why you have the #define but it forces us into a "build-time" setting. For pages and services this might be the right option. For other options, it will not be the right option. I think we should try to make things configurable at runtime first, and revert to build time if we are forced to for some reason.

For example, in the case of a KBox variant, I think the built time configuration is the only thing that makes sense but we can do it with a dedicated target and a build time -DKBOX_MINI_VARIANT.

100% d'accord
Yes, this was the idea, just for services and pages and nothing which could be made at runtime.
This #define was just my minimalistic approach with my low level skills of C++
(knowing not enough to do this target thing... ;-) )

Foot notes:
1.) So it all depends of: what happens if we take and display a value, let's say every second.
Does it jump around and become unreadable?
E.g. May be BNO055's fusion output is that good, that it doesn't need any display-filter at all?

2.) If the setting is "take heading/heel&pitch from N2k-Bus, an own external IMU-sensor on serial input" then the page should show that values.

sarfata

This is really really cool. I have not tried the latest version on a KBox yet but I will give it a go as soon as you have a way to save calibration too. I am excited, this is a very important feature!

sarfata · 2017-12-31T06:28:45Z

lib/Adafruit_BNO055/Adafruit_BNO055.cpp

 */
 /**************************************************************************/
-bool Adafruit_BNO055::begin(adafruit_bno055_opmode_t mode)
+bool Adafruit_BNO055::begin(adafruit_bno055_opmode_t mode, uint8_t axis_remap_orientation, uint8_t axis_remap_sign)


sarfata · 2017-12-31T06:29:12Z

lib/Adafruit_BNO055/Adafruit_BNO055.cpp

@@ -90,8 +88,7 @@ bool Adafruit_BNO055::begin(adafruit_bno055_opmode_t mode)
    //delay(100);
  //}
  //delay(50);
-
-  DEBUG("rebooted");
+  //DEBUG("rebooted");


we should just remove this I think.

If you do not need your remarks anymore, I can delete them.
But added you as collaborator, so you can make modifications too, if you want.

sarfata · 2017-12-31T06:30:57Z

src/host/config/KBoxConfigParser.cpp

+  config.imuConfig.enabled = true;           // enable internal IMU sensor
+  config.imuConfig.enableHdg = true;         // true if values taken from internal sensor
+  config.imuConfig.enableHeelPitch = true;   // true if values taken from internal sensor
+  config.imuConfig.calHdg = 3;               // hdg valid, if calibration value greater equal


I am still not convinced we need this. Besides you, and to a lesser extent me, nobody is going to understand what those values mean.

If I agree to make 3 and 2 the defaults, are you ok removing this? ;)

:-))
yes, this is ok.
As I can see the heading on the IMUPage now (independently from the SKUpdate, which means independently from any cal-value) it is ok for me.

I have to delete it then in the config too. But would prefer to do it in a separate PR after merging, if it is ok for you.

sarfata · 2017-12-31T06:31:16Z

src/host/main.cpp

@@ -134,6 +135,12 @@ void setup() {
  BatteryMonitorPage *batPage = new BatteryMonitorPage(skHub);
  mfd.addPage(batPage);

+  if (config.imuConfig.enabled) {


👍 great idea.

sarfata · 2017-12-31T06:32:12Z

src/host/pages/IMUMonitorPage.cpp

+}
+
+bool IMUMonitorPage::processEvent(const ButtonEvent &be){
+  // DEBUG("EventTypeButton: %i", be.clickType);


We need to come up with a better way to disable logging for just one class. Commenting DEBUG is really not ideal, and removing them is also not great. I need to come up with something!

A lot of this DEBUG I just need during inventing of code. Then, when I think it works as I expect, I think it is a pity to delete them....

sarfata · 2017-12-31T06:36:47Z

src/host/services/IMUService.cpp

+// all angles in radians
+void IMUService::getLastValues(int &accelCalibration, double &pitch, double &roll, int &magCalibration, double &heading){
+  accelCalibration = _accelCalib;
+  pitch = _pitch + _offsetPitch;


is it possible that the offset pushes the value beyond a theoretical maximum?

For example max pitch is +180, if the boat is pointing down and the offset is 5 degrees, we could have 179+5=184 which would be outside our range. Maybe we should apply some normalization here.

The offset is meant for doing small corrections only, not for correcting mounting positions. E.g. after loading people, water, luggage.
If pitch is around 180 then you have (other) problems :-)
If someone is sailing with heel 40° and wants to do have heel 0 on the display then this would be crazy.

sarfata · 2017-12-31T06:37:25Z

src/host/services/IMUService.cpp

-  heading = fmod(eulerAngles.x() + 270, 360);
+  // TODO: different calcs according to mounting position
+  /* if orientation == MOUNTED_ON_STARBOARD_HULL */
+  _roll = SKDegToRad(eulerAngles.z());


why dont you apply the offset here?

With the position-mounting-config the calculation must be done for each position then.
So I have the calculation just twice in the code.
But if you like we can change, because it makes sense to have a clear, ready calculated value for update.

sarfata · 2017-12-31T06:38:37Z

src/host/services/IMUService.cpp

+    _offsetRoll = _roll * (-1);
+    _offsetPitch = _pitch * (-1);
+    INFO("Offset changed: Heel -> %.3f | Pitch -> %.3f", SKRadToDeg(_offsetRoll), SKRadToDeg(_offsetPitch));
+    // TODO: angle of heel and pitch must be smaller than 90°, check overflow!


yes this is what i meant in my comment above :) I see you thought about this already.

So, yes, in theory the value could be pushed to an out of range value, but I do not know if normalization is really needed.....?

sarfata · 2017-12-31T06:39:58Z

src/host/services/IMUService.cpp

+  EEPROM.put(_eeAddress, bnoID);
+
+  _eeAddress += sizeof(long);
+  EEPROM.put(_eeAddress, newCalib);


Have you tried using the src/host/util/PersistentStorage.cpp? Do you want me to help with this?

To be honest, I do not understand the PersistentStorage up to now, or did not look at it for longer to really understand it. ;-)

I thought that the calibration values are stored in the MCU of the BNO055 directly, so it is not needed here anyway?

If it is possible to use it here too, then I would need your help please.

Correction 2.1.2018:
it is not possible to store values into the BNO055!
But it is not sure, if it is wise to store calibration/offset values and load them at start of KBox.
See more: Issue #86

sarfata · 2017-12-31T06:43:46Z

src/host/services/IMUService.cpp

+	if (_accelCalib >= _config.calHeelPitch && _gyroCalib >= _config.calHeelPitch) {
+    update.setNavigationAttitude(SKTypeAttitude(/* roll */ _roll + _offsetRoll, /* pitch */ _pitch + _offsetPitch, /* yaw */ 0));
+    //DEBUG("Heel = %.3f | Pitch = %.3f | Heading = %.3f", SKRadToDeg( _roll + _offsetRoll), SKRadToDeg( _pitch + _offsetPitch), SKRadToDeg(_heading));
+    _skHub.publish(update);


You should publish only once. Not twice.

With the current code, if both are calibrated you will send one update with heading first and then one update with heading + attitude. I do not think this is what you want.

OK, then I did not understand the update.

can I write _skHub.publish(update);
just once, regardless if there was update.setAttitude.....?
(Like I have it now?)

sarfata · 2017-12-31T06:46:12Z

Also let me know when you want to merge. I think besides a few details/nitpicks I mentioned above we could merge as-is and do more PRs for the rest.

coveralls · 2017-12-31T11:25:11Z

Coverage decreased (-4.4%) to 67.902% when pulling cc71273 on ronzeiller:rz_imu-page into 2eab8fd on sarfata:master.

coveralls · 2017-12-31T11:35:57Z

Coverage decreased (-4.4%) to 67.902% when pulling 621c5d0 on ronzeiller:rz_imu-page into 2eab8fd on sarfata:master.

ronzeiller · 2017-12-31T14:14:38Z

@sarfata
Hi Thomas,
yes, if there are no fundamental errors anymore, it would be nice if you could merge.

As I have worked already on the positioning config this feature is already in this PR too.

Just to keep in mind the TODO's:

may be do the offset calculation before and not in SKUpdate
Change to PersistentStorage?
Adafruit library delete uncommented code

CaptainRon47 · 2017-12-31T16:21:39Z

All, I am trying to follow what you are all doing and I thought I would (finally) try and do it using GitHub. In the past I would just copy a zip file and open in my desktop with Atom. So I created my own Repository (on the GitHub website) and imported RonZ’s latest updates (as of this morning, but changes still going on I see). Then I cloned this into my desktop GitHub and opened it with Atom. Now the question is, as changes are made by RonZ (for example: in experiment/chibios – less than a minute ago) will those changes show up in my Repository on the web and or on my desktop version, or is my clone frozen as it is? I guess I will find out shortly! Happy New Year, Ron From: Thomas Sarlandie [mailto:[email protected]] Sent: Sunday, December 31, 2017 10:50 AM To: sarfata/kbox-firmware Cc: CaptainRon47; Mention Subject: Re: [sarfata/kbox-firmware] IMUMonitorPage added (#89) @sarfata commented on this pull request.

_____ In src/host/pages/IMUMonitorPage.cpp <#89 (comment)> :

+ return true;

+} + +bool IMUMonitorPage::processEvent(const TickEvent &te){ + _imuService.getLastValues(_accelCalibration, _pitch, _roll, _magCalibration, _heading); + //DEBUG("AccelCalibration: %i | MagCalibration: %i", _accelCalibration, _magCalibration); + + // TODO: Some damping for the display + _hdgTL->setText(String( SKRadToDeg(_heading), 1) + "° "); + _calTL->setText(String( _magCalibration) + "/" + String( _accelCalibration) + " "); + _pitchTL->setText(String( SKRadToDeg(_pitch), 1) + "° "); + _rollTL->setText(String( SKRadToDeg(_roll), 1) + "° "); + + // Always show Hdg from IMU-sensor, but if the value is not trusted (which means + // calibration below config setting, change color to red + if ((_magCalibration <= _config.calHdg)||(_accelCalibration <= _config.calHeelPitch)) { Re-Indent: this article might help: https://stackoverflow.com/questions/4119872/netbeans-removing-trailing-whitespace-on-save-and-tabs-to-spaces I think your editor is configured to show tabs as 2 spaces. this is why it looks good to you. But since they are actually tabs, it does not look good in github (they do this on purpose to make it easier to detect). I can push a commit to fix it if needed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#89 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AP9zq8pOj1pHDbc5Z5fz_r1wIlg8kXrOks5tF60MgaJpZM4Q8Svr> .Image removed by sender.

…ware into rz_imu-page

coveralls · 2018-01-01T17:37:52Z

Coverage decreased (-4.2%) to 68.104% when pulling 4edf570 on ronzeiller:rz_imu-page into 2eab8fd on sarfata:master.

coveralls · 2018-01-01T17:45:05Z

Coverage decreased (-5.6%) to 66.667% when pulling cb01893 on ronzeiller:rz_imu-page into 2eab8fd on sarfata:master.

coveralls · 2018-01-01T18:30:17Z

Coverage decreased (-4.5%) to 67.807% when pulling 9b18505 on ronzeiller:rz_imu-page into 2eab8fd on sarfata:master.

ronzeiller · 2018-01-01T19:48:31Z

@CaptainRon47 CaptainRon47
Hi Ron,

Happy New Year to you too!

I am trying to follow what you are all doing and I thought I would (finally) try and do it using GitHub. In the past I would just copy a zip file and open in my desktop with Atom. So I created my own Repository (on the GitHub website) and imported RonZ’s latest updates (as of this morning, but changes still going on I see).

You should go to my github and do a fork -> then you get a copy of my work. It is then connected to my github which makes things easier for you to update.
Be aware, that my code is often just for discussion for new features or beta code.

I would strongly recommend to fork the original from @sarfata
Also the good new config stuff you will get there!

After forking, you clone again, to get a local working copy.

Now the question is, as changes are made by RonZ (for example: in experiment/chibios – less than a minute ago) will those changes show up in my Repository on the web and or on my desktop version, or is my clone frozen as it is?

This is the status and it does not change automatically.
For update you can do something like this directly in the terminal of Atom:
(You have to do this only once)

git checkout master (....or the branch name you like to update)

git remote add upstream https://github.com/sarfata/kbox-firmware.git

Now you are connected to your own "github" and the original "sarfata-code" called "upstream" in this example.

This shows you the different remote names:
git remote –v

For example I have here (github and upstream are just names, you could take different here):

github  https://github.com/ronzeiller/kbox-firmware.git (fetch)
github  https://github.com/ronzeiller/kbox-firmware.git (push)
upstream  https://github.com/sarfata/kbox-firmware.git (fetch)
upstream  https://github.com/sarfata/kbox-firmware.git (push)

For updating master from sarfata I just do:

git checkout master
git reset master to upstream/master       (master or the name of the branch I want to update....)
git fetch upstream
git reset --hard upstream/master
git push --force

Then my github and my local working copy is up-to-date again with all changes sarfata made.

Then the best is to create a new branch in Atom to work and develop, or with your special adjustments......
You can later always merge new things to this branch too.

For all of this and a lot more, you will find really good descriptions in google on github or stack exchange.

Good luck!

CaptainRon47 · 2018-01-01T22:38:14Z

Thanks for the helpful discussion. I must admit I am intimidated by the unfamiliar terminology (pushes, pulls, forking, etc). In principle I understand what is happening but not having lived with this open programming environment for long I tend to play it safe and just copy a zip file to my local machine and work with that. But, as I said, I am trying to ‘get with it,’ and start to use GitHub as intended. I did ‘import’ RonZ’s IMU_Page version into my own Repository as a ‘new’ project and then cloned it to my pc. I wanted to see the latest changes with the new display page and the NMEA outputs activated. I will try your suggestion of ‘forking’ the repository at the next release from Thomas.

And so the GOOD news is that it all works! I get the IMU page in the display! I reconfigured the speeds on the NMEA1 and 2 inputs/outputs to match my equipment and I modified the IMU orientation to reflect my VerticalToptoBow mounting. I changed these in KboxConfigParser.cpp since I am not sure if the idea of a config file on the SD card is working in this version. I get the correct Roll and Pitch data on the display (a long push on the button does zero out the values) and also get NMEA data out on both NMEA1 and 2 at the correct speeds. The Wifi data and the USB output all looks good. I see that the current USB output is back to being a DEBUG output, which is fine now that the NMEA outputs are working, as I can use that to connect to my Rpi running OpenCPN instead of the USB. I have been unable to test if SignalK data is available from Kbox as my Rpi is acting up!

Now the NOT SO GOOD news, my USB connector attachment came off of the Kbox board. I probably am a bit more active, than most, in moving the Kbox from my boat to my office where I make programming changes. In the office the USB cable (I have a long one) hangs off the desk to connect to the PC tower on the floor. The weight of the cable and movement from boat to office was enough handling to loosen the connector on the board. I leave the USB cable plugged into the Kbox all the time, but I did not think to build a strain relief to the plastic box. I did drill a hole in that box so the USB cable could be plugged in while the board was in the box and I should have added strain relief as the pinout cables have. I was able to solder the connector attachment back to the board and I at least get power, but I did not get all 5 tiny pins soldered back down so I don’t get a USB port for programming the Kbox. My soldering skills and equipment are not up to that task.

Thomas,
Send me a private email and we can discuss what you want to do.

Thanks,
RonS

sarfata · 2018-01-03T02:27:03Z

@CaptainRon47 I have sent you an email. We will get this fixed. Thanks for your time testing and playing with KBox!

ronzeiller added 7 commits December 9, 2017 20:45

Netbeans project folder added

bd9cb0c

initial commit with some settings for IMUService & IMUMonitorPage

ab7ccfb

initial commit with some settings for IMUService & IMUMonitorPage

9fc5355

Start of simplified IMUMonitorPage

9cc6d2e

Start of simplified IMUMonitorPage

1e183f4

include KBoxConfig, IMUMonitorPage, settings for service intervals

e9ad204

MagHdg and heel/pitch update separated to diff. calibration settings

14a7546

sarfata reviewed Dec 10, 2017

View reviewed changes

sarfata changed the base branch from develop to master December 10, 2017 05:04

sarfata changed the base branch from master to develop December 10, 2017 05:25

sarfata changed the base branch from develop to master December 10, 2017 05:25

ronzeiller added 6 commits December 11, 2017 01:23

Some functions added for IMUMonitorPage

7898cb9

Some functions added for the IMUMonitorPage

e9b4cea

more defines, passing a reference to IMUService for IMUMonitorPage

b67754c

reference to IMUService added

f041061

getLastValues from IMUService added

de083c1

KBoxConfig moved to src/common/config, 2 more service-defines added

d11d220

sarfata reviewed Dec 11, 2017

View reviewed changes

ronzeiller added 6 commits December 11, 2017 22:39

extended with button long click for offset-to-zero of heel/pitch

db7fa77

extended with button long click for offset-to-zero of heel/pitch

100a6d4

make write8() public to access from IMUService

24b5ec4

axis- and sign remapping cancelled here as made on start of IMUService

1229eb4

ButtonEvent LongClick added, default for switch page is Click now

f45d445

changed to ButtonEventTypeClick for switching patches

91f52d2

sarfata reviewed Dec 31, 2017

View reviewed changes

ident to tab 2

621c5d0

small corrections, config for mounting

a818895

ronzeiller and others added 2 commits January 1, 2018 19:34

indent corrected

4edf570

Merge branch 'rz_imu-page' of https://github.com/ronzeiller/kbox-firm…

fe3ee96

…ware into rz_imu-page

indention corrected

cb01893

ronzeiller added 10 commits January 1, 2018 19:50

indent corrected, not used function deleted

f2aa14d

indent corrected, not used function deleted

333242e

IMU calibration values deleted from config

69007d2

IMU calibration values deleted from config

03c048c

IMU calibration values deleted from config

dc36c58

IMU calibration values deleted from config

2c87d62

put back updateReceived due to error message....

019d7e7

put back updateReceived due to error message....

2be63c3

not needed debug msg deleted

2abe954

prevent overflow by setOffset

9b18505

ronzeiller mentioned this pull request Jan 2, 2018

Write & Read BNO055 Calibration and heel/pitch offsets to/from EEPROM #110

Merged

sarfata merged commit 9b18505 into sarfata:master Jan 8, 2018

ronzeiller deleted the rz_imu-page branch February 11, 2018 11:42

		#include "signalk/SKUnits.h"


		IMUMonitorPage::IMUMonitorPage(SKHub& hub, IMUService &imuService) {


		hub.subscribe(this);

		imuService.getLastValues(_accelCalibration, _pitch, _heel, _magCalibration, _heading);

IMUMonitorPage added #89

IMUMonitorPage added #89

Conversation

ronzeiller commented Dec 9, 2017 • edited Loading

coveralls commented Dec 9, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sarfata commented Dec 10, 2017

coveralls commented Dec 11, 2017

ronzeiller commented Dec 11, 2017

sarfata commented Dec 11, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ronzeiller commented Dec 11, 2017

sarfata left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ronzeiller Dec 31, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ronzeiller Dec 31, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ronzeiller Dec 31, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sarfata commented Dec 31, 2017

coveralls commented Dec 31, 2017

coveralls commented Dec 31, 2017

ronzeiller commented Dec 31, 2017 • edited Loading

CaptainRon47 commented Dec 31, 2017 via email

coveralls commented Jan 1, 2018

coveralls commented Jan 1, 2018

coveralls commented Jan 1, 2018

ronzeiller commented Jan 1, 2018

CaptainRon47 commented Jan 1, 2018

sarfata commented Jan 3, 2018

ronzeiller commented Dec 9, 2017 •

edited

Loading

ronzeiller Dec 31, 2017 •

edited

Loading

ronzeiller Dec 31, 2017 •

edited

Loading

ronzeiller Dec 31, 2017 •

edited

Loading

ronzeiller commented Dec 31, 2017 •

edited

Loading