Barometer histogram to short.

[trudK45]

I have a barometer connected to input of OpenCPN. Works fine but the length of the histogram is way to short (1 h only). To be of use I think this needs to be extended to something like 24 h. /Hans

[ghost]

Hi, I was involved in 1.0.11 baro history changes and testing. You are right, in memory there is only place for 3000 samples. Increase that memory? Let's see: the baro history works now on ticks which occur every one second - data is sampled and a small dot is drawn on the scaled window. These dots give you some extra time, see the below picture taken after 8 hours of sailing test - you would need to widen the window and more time will remain visible on the graph. Of course, both of the methods are very ephemeral, increasing the number of dots in a volatile memory, would that be a safe option? You close the window and reopen it, data is gone. Same if you need to restart OpenCPN. 24 hours is a long time.

That's why the data can be stored in 10, 20 and 60 seconds interval in a CSV file to be visualized with the tool of your choice. Also, it is possible to stream the data into a time series database for visualization underway or back home, while your data remains safe as long as you want it. It would be indeed a nice feature if the baro history window could read and visualize data back from the external data storage system it is writing into, and that for user's convenience. The 24h visualization requirement could be fulfilled in a safe way.

[trudK45]

Hi Canne!

Well , when it comes to barometric pressure there is no need to store every second of data. As you are mostly interested when a depression is closing in you want to see the how rapid the pressure falls. I think it's even overkill with a saved value every 10 or 30 seconds. With 3000 data you could then save either, well over 8 hours or 25 hours.

I would like to see a feature in watchdog where you can set an alarm if the pressure decreases at set value of the slope. Also there should be an alarm for depth. I may do something with that plugin for this.

I have designed and built my own barometer. At the moment it got no data input,only NMEA output but if added it would be possible to store the values in flash and by command read out the saved data However I can not see how this would not be compatible with NMEA. The data would need to be timestamped.

I am a bit confused over all the different versions of tactics out there. For OpenCPN V5.0 I have downloaded these.

tactics_pi-1.0008-ov50-win32 tactics_pi-1.0009-win32 tactics_pi-1.0.25-ov50-win32

I have seen tactics_pi-1.0.11 and tactics_pi-1.0.13

tactics_pi-1.0.11 seem to be the official source but when building and installing that it crashes Can you tell me what source I should be downloading ?

/Hans

[ghost]

Hello Hans,

We're on the same page! I am looking right now my old faithful Bohlken Westerland barometer: it has all the features you mentioned and I can tell that when it makes its long beep everybody starts to put their storm gear on without further ado! I would suggest to have also an alert on the upward fast slope as well, it is very dangerous signal here in the Mediterranean.

You should use this (Thomas') repository as reference, the open source wonderful world is not here to make your life easier but if you follow the forks, you'll end up here. The 1.0.25 is made by Rick in his much appreciated effort to make readily build packages available for people. Apart some version number tricks he was obliged to do it is the same what you are reading here now.

It is a surprise that you cannot get your build from here running. I just check my fork being in sync with this one (it was), compiled it nevertheless from scratch, tested in Win10 OV50 shortly, no crash and some instruments appeared. I did not test any further but if you like, I attached here my build output: 2019-11-16_1-0-11_tactics_buiild_win20_RelWithDebInfo.zip

I suggest that you keep the initial tick in one second:

We change it to 5 seconds once the clock hits nice even numbers. So, you see that we're already undersampling. You can change that sampling rate to be even lower but you need to consider few points that follows:

• The vertical 15 minutes marks probably need to be reconsidered;

• The moment when the export (CSV-save) function is called.

I think it is best you make your own fork, figure out why it is not building correctly for you and then go on and try it out! Please keep this thread informed about how your project is moving on (Arduino or Raspberry Pi piggy-bag or something else?), your contribution is highly appreciated.

Best regards,

Petri

P.S. & BTW: I have a Miniplex multiplexer which can be configured entirely with proprietary "NMEA-0183" sentence, example $PSMDCF,a,b,rrrrr,t*hh<CR><LF> for setting the baud rate. So don't worry about using your own sentences to command your device, NMEA-0183 is wild west not a standard and OpenCPN will happily ignore your sentences.

[ghost]

For completeness sake, I compiled also on Raspberry Pi 4B and tested the .so generated from this same repo. No issues in the startup and I was able to add some instruments. In case you have a Raspberry, see tactics_pi_1.0.11-ov50-1_armhf.deb.gz - if you have another distro or CPU architecture, check those builds from Rick's repo (1.0.25).

[rgleason]

Dear Hans [trudK45], Thomas and Petri,

I apologize for the fork mess. I've been building tactics exe for Thomas since the beginning and things have evolved. There are several versions. We now have

• Thomas/Petri highly accurate version 1.0.11
• A version that Jon Gough and I worked on to cleanup the cmake files, build all necessary OS, etc. but does not have the improvements. I released that as 1.025 while Thomas and Petri were stilll working on v1.011
• Then to get version 1.11 building for various OS, I changed v1.0.11 to v1.0.13 Perhaps I should keep it v1.0.11 even if it is slightly different? Once we get this sorted I can ask kathi to post it as the official release.

Incidentally, it would be very helpful if Thomas were to get his own free appveyor and travisCI accounts, so that these releases can be hosted on his repository. When OpenCPN v5.0 came out the only way we were going to get updated plugins was by just doing it. Pavel has done this in the past I believe, but he has been very busy. So I just took it on to fill in the blanks for many plugins.

This situation should improve in time.

[trudK45]

Canne! I am running win7 on a fitPC. I have updated to wxWidgets-3.1.2 and am in the process of another try with tactics. I will stick to Thomas tactics. Will get back with results. /Hans

[ghost]

Hi Rick,

don't apologize, you are doing the work Pavel used to do and somebody needs to do it, we all appreciate your effort. Using cloud CI is pain in the neck and tag numbers are flying by.... For the end user they should refer to the official version number whatever you and Kathi decide being the good one. For those who want to browse the Github and/or various forum posts they should take their responsibilities and find the source they want to use.

This is not my repo but as a developer myself I can well understand if Thomas does not want to get into the business of package building - it is really painstaking and time consuming as you have certainly find out.

The situation is already quite good thanks to your efforts but what needs to improve perhaps is the communication to end users and to developers apart.

As a friendly advise maybe you can use the good old trick to reach the actual version number slowly with test builds using crazy patch numbers for tags, like 1.0.1091, 1.0.1092... etc. while you are approaching the tag you want to have, 1.0.11.

Now, you need to get an agreement with Thomas for the next version in advance, say it can be 1.1.0, why not. Then you would make 1.0.91 1.0.92 as release candidates until you are sure that you can reach 1.1.0. If somebody is complaining about the intermediate versions while they are clearly marked as release candidates, that's their problem! 😁

Keep up the good work, Rick!