AvNav - navigation in the browser

[ekoleponen]

Basically the same errors, I have not watched whether they come from the same place (z, y, z).

Just now when I started, the preFill handled the EE-chartset also.
Also a new ERROR I have not seen before "no chart info cache found".

But anyway the extra preFills are over so quickly that I would hardly notice them unless I jumped directly to watch the ocharts-plugin-prefill operation immediately after starting AvNav.

[ekoleponen]

Hello again !

AvNav has been working ok, but there is a problem that buoys are vanishing or they are not presented at all.
The charts are ocharts, uploaded via zip-files to AvNav and loaded via the ocharts-plugin to Ocpn5.6.2.
The chart set is Finland (surprise surprise...).

The place is the narrow red/green channel going northeast from about the center of the pictures.
The attachments show a situation where zooming-in AvNav the red/green buoys are missed totally.
In zoom-level 13 the red/green buoys are visible and in the level 14 they are gone totally.
As a reference there is the Ocpn5.6.2 view of the same place. The buoys stay invisible on larger zoom levels (15, 16)

No error messages are generated.
I am not using AvNav and Ocpn at the same time.

Any ideas?

[wellenvogel02]

No idea out of the box.
I have to check this in more detail.
Could you provide a log file ( provider.log) that contains a startup?

[ekoleponen]

Here is the provider.log

[wellenvogel02]

Ok, took me some time to have a look.
Still no idea what's going wrong.
I made some computation from the log and your chart center to see which charts are contributing there.
Found the following ones (x,y and zoom):

4706	2357	13	/home/pi/avnav/data/ocharts/charts/oeuSENC-FI-2022-10-18-base-sgl001DF91A/OC-358-ZUJIE4.oesu
4706	2357	13	/home/pi/avnav/data/ocharts/charts/oeuSENC-FI-2022-10-18-base-sgl001DF91A/OCL358-RTAOBL.oesu
9413	4715	14	/home/pi/avnav/data/ocharts/charts/oeuSENC-FI-2022-10-18-base-sgl001DF91A/OC-358-831S95.oesu

(1) Do the buoys appear on higher zoom levels? (Most probably not)
(2) could you check in OpenCPN which charts you have at this place (should be visible at the bottom)?
(3) If those are all the same could you send me the ChartList.XML from the directory with the finnish charts?

(4) Next would be some more complex test.
Would be very helpful to move all other chart files except the 3 I mentioned into some other directory for a moment (but keep all the XML and txt files in place).
To make the logs smaller, just move away the other chart directories (except finnland) under /home/pi/avnav/data/ocharts/charts into some other place for the test.
To stop the prefiller you should set the prefillZoom in the plugin settings to 0 before you restart AvNav.
And you could set the debugLevel to 2 in the ocharts plugin settings.
Afterwards restart AvNav, navigate to the interesting area and keep the provider.log.
Basically I could image a couple of issues:
(1) still some errors when loading the charts
(2) wrong computation of scales

Maybe if you do not see any errors in this test in the log it could be helpful to repeat this again with the patched library (sub dir bullseye-arm64-diag).

I know - it's a lot of effort ....

[ekoleponen]

(1) no they do not reappear, buoys stay invisible at levels z14 -z18
(2) the three you listed are the same, also Ocpn562 lists OC-358-A600A5.oesu (off the area to the west) and OC-358-EFOG92.oesu (Ocpn lists it with green/grey rectangle)

(3) attached
(4) to be done in near future if still necessary...

By the way, found another place, where AvNav shows no buoys on every zoom level even though they are there and Ocpn562 shows them...

[wellenvogel02]

Yes, the test at (4) would still be very helpful. Maybe just run it with the patched library that has more debug info for us.

Maybe as an intermediate check you could disable "reduce detail on small scale" and try if this shows the buoys...

[ekoleponen]

Test (4) done, logs too big for this forum, mailed them directly to you.

[wellenvogel02]

Many thanks.
Will have a look.

[wellenvogel02]

Ok, after further analyzing it turned out to be a bug in AvNav (especially in the ocharts-provider).
https://github.com/wellenvogel/avnav...ider/issues/41
A daily build is on the way, packages should be there within two hours.
After some testing I will create a new release for avnav-ocharts-plugin.

[ekoleponen]

Thanks for your hard work !!

[sparticle]

Hello Andreas,

Firstly I wanted to thank you for the amazing work on bringing a very innovative and modern approach to realtime navigation.

I have been using Rpi's since they arrived in 2012, we used a 3B and then B+ for a number of years running OpenCPN for many thousands of miles of sailing and many ups and downs with the software and interfacing on the boat.

With the newer rpi4 the power is there now to provide a reasonable experience and we can run our favourite distro Ubuntu as the base system. General purpose boat computer and navigation station.

Having gone through most of the software out there over the years your approach is interesting. Browser connection to a server based navigation computer.

We recently built a RPI4 AVNAV server using the latest image on your site, totally headless now after config using a screen keyboard and mouse. And after a few trials we managed to get it up and running. We use a USB key for the o-charts. Full UK and near Europe and the German bight etc.

Right now we are running in parallel with our RPI4 Ubuntu Nav Computer running OpenCPN and consuming a UDP feed out of OpenCPN using the UDP reader we configured.

It seems to get all data and shows boat data correctly and AIS targets for approx. 30NM

We are having a few challenges with chart drawing/redrawing or not as the case may be. Sometimes it seems to get stuck and not redraw the onscreen area after moving the cursor around or zooming. Chunks of charts not lining up so blank areas on screen. A redraw button would be useful unless there is one and we have missed it.

Also can you advise how we see the raw NMEA stream as we set this up to ensure we are getting what we need.

We have a hybrid sytem onboard with a classic Raymarine tri data fit that talks to the RPI Nav computer using a USB to Raymarine 85001 and brings the ST1 data (Heading, Depth, Speed, Wind etc.) into OpenCPN. We have a Digital Yacht 5K AIS which brings the GPS and AIS data in via USB and we send out AP data to the 85001 for onward transfer to the ST1 Network. This generally works ok and the Raymarine ST1 network gets all the GPS and course data that way.

We also consume the OpenCPN UDP stream using phones and tablets and the main saloon TV (via RPI4 Android 12) running Navionics Boating App. As you probably know the Boating AP is crippled as it cannot output to an AP which is a shame as it is a good app but useless for actually driving a route.

Your solution shows much promise but it is a bit slow at rendering on the mobile/tablets browsers. The boat network is a 5G Wifi Network.

Are there tunables or tweaks to improve the rendering or is it all client side? Utilisation on the RPI AVNAV is not an issue it seems there is plenty of headroom.

Clearly right now the RPI AVNAV is not the primary MUX it is getting a MUXED data stream via UDP from OpenCPN, but in an imagined future it would be the centre of the system. Is the RPI4 4GB man enough to MUX all the various feeds and drive potentially multiple browsers showing the same route and nav info?

Are the various browsers capable of looking at other things. i.e. can one be set to display the instruments and another the moving map/route etc. Or another be planning a route? We ahve seen warning messages saying too many clients to display a chart for instance. That was with 2 devices. It went away when we clicked on another chart then came back to the first one.

We would be happy to do some testing for you as we investigate the potential in this approach. We will continue to feedback to this forum as we expeiment.

Cheers
Spart

[wellenvogel02]

Hm - lot of questions...

We are having a few challenges with chart drawing/redrawing or not as the case may be. Sometimes it seems to get stuck and not redraw the onscreen area after moving the cursor around or zooming. Chunks of charts not lining up so blank areas on screen. A redraw button would be useful unless there is one and we have missed it.

Does this happen with o-charts or also with other charts?
Reload is not (yet) there. Short trick: click overlay edit and save...
For ocharts: have a look at /home/pi/avnav/data/ocharts/provider.log (or if you have it on some other system - path without "data") - just check for errors like render timeouts.

Your solution shows much promise but it is a bit slow at rendering on the mobile/tablets browsers. The boat network is a 5G Wifi Network.

This is really surprising. Would be helpful got get more details on this. Typically I run a Pi3B on my boat feeding 2 tablets and a phone without any issues at all.
For o-charts there could be some delays when you zoom in somewhere for the first time but afterwards it should be fast as the tiles are cached on the Pi.
Which browser are you using? On mobile devices (android) I test with the stock browser (chrome) or with (my) BonjourBrowser (that uses the system chrome engine).
No problems at all.
What about the network?

Are there tunables or tweaks to improve the rendering or is it all client side? Utilisation on the RPI AVNAV is not an issue it seems there is plenty of headroom.

o-charts rendering is on the pi. Unfortunately the main renderer runs single threaded, i.e. can only use one of the cores (limitiation of the used OpenCPN plugin).
And loading stuff from the SD card can also become an issue (I had a couple of SD cards that became slow over time).
For o-charts you can try to tune in the main settings - overZoom/underZoom - they influence the number of charts that potentially get rendered.
You can also give the ocharts stuff more memory - AvNav server/settings, plugins->ocharts: Set some % of your system memory. Giving it 500MB or some more can help.

Also can you advise how we see the raw NMEA stream as we set this up to ensure we are getting what we need.

All received NMEA data will be send out at port 34567 (if you have the default set up). Just use a command like "nc localhost 34567" to read the data.
Alternatively you can configure the nmea logger (server/status page) - set interval to 0 and remove the filter. You will find the nmea logs in the tracks directory.

Clearly right now the RPI AVNAV is not the primary MUX it is getting a MUXED data stream via UDP from OpenCPN, but in an imagined future it would be the centre of the system. Is the RPI4 4GB man enough to MUX all the various feeds and drive potentially multiple browsers showing the same route and nav info?

Should be no issue at all. The muxing does not take too much power. And you can easily drive a couple of clients.
In principle you could increase the number of threads used for HTTP processing if you have many clients (use the config editor from the update plugin - AVNHttpServer - see https://www.wellenvogel.net/software...e.html?lang=en) - but this was never necessary until now.
The only issue would be the wifi access point of the pi if you would use this one. This seems to be really limited in the number of clients (and in stability at all...).

Are the various browsers capable of looking at other things. i.e. can one be set to display the instruments and another the moving map/route etc. Or another be planning a route? We ahve seen warning messages saying too many clients to display a chart for instance. That was with 2 devices. It went away when we clicked on another chart then came back to the first one.

Yes, you can display different stuff on every browser (you can even use the split mode to do this in one browser). I would not really recommend using multiple browser windows/tabs on one device - it basically works but some things could be surprising as they share the local storage of the browser (split mode handles this).
There is one limitation for the o-charts stuff - max. 5 clients displaying charts are allowed at a time - see https://www.wellenvogel.net/software...2:LicenseNotes). Once a client is detected it will remain valid for some time even if you leave the page (5 minutes). But you can use more browsers for e.g. displaying dashboard pages.

[sparticle]

Andreas,

Thanks for the reply. I will be back onboard tomorrow so will try out your suggestions.

Does this happen with o-charts or also with other charts?

We only use official charts as provided by O-Charts and they are always updated to the latest.

Which browser are you using?

All the devices are either Android phone/Tablet/Android 12 on the big screen using standard browser (chrome I believe).

What about the network?

The boat wifi network is provided by a Teltonika RUTX11 mounted externally on the wind turbine pole inside a dedicated housing. https://quwireless.com/quspot-rutx11

The network is very stable and performs really well on iperf tests.

You can also give the ocharts stuff more memory - AvNav server/settings, plugins->ocharts: Set some % of your system memory. Giving it 500MB or some more can help.

This sounds good as we have 4GB in the RPI4 AVNAV server. I am just playing with this now so will report back.

The only issue would be the wifi access point of the pi if you would use this one.

We use the RPI AVNAV wifi as a client only. It is totally headless and simply has power to it at present. It connects to the boat wifi as a client.

There is one limitation for the o-charts stuff - max. 5 clients displaying charts are allowed at a time - see https://www.wellenvogel.net/software...2:LicenseNotes). Once a client is detected it will remain valid for some time even if you leave the page (5 minutes). But you can use more browsers for e.g. displaying dashboard pages.

This should not be a problem for us. 5 works fine for us. The Saloon TV if others want to see what's going on by using the 2nd HDMI input. Plus the nav station plus the helm station plus the skippers tablet

Thank you for the support. Please forgive any typos or grammar.

In classic Columbo fashion.....What about overlays for Grib data is there a plugin for this?

Cheers
Spart

[sparticle]

Andreas,

Just some initial feedback.

Whenever we connect a device like a Samsung Galaxy S21 Ultra via browser or a Samsung Tablet. On first connection we get the error that we cannot connect to the chart as too many connections. Exiting that chart and clicking on another then going back to the primary chart results in the chart loading.

We have set the memory to 50% of the available memory or 50% of 3.7GB and set number of threads to 10 double the default and cache to 100,000 from 10,000.

We have some improvements in rendering. But after many hours of constant scrolling and zooming of the primary chart the memory usage is still under 1GB with it seems still plenty of CPU headroom.

We currently see two processes with many children for the secod utilising essentially a full CPU thread each. See image attached.

Not sure why there are so many threads around sounds as nothing is using sounds that we are aware of.

We are about to insert the Rpi4 AVNAV server into our network connecting the DY AIT5K via USB and the DY USB to NMEA adaptor connected to the Raymarine E85001 which is currently used as a bi-directional conncetion LS NMEA getting the useful Raymarine ST60+ data Wind, Depth, Speed in and sending the OpenCPN RMB,APB Autopilot feed out for onward transmission to the Raymarine ST6001+ AP Controller via the 85001.

We would need to recreate the UDP output to the local network that we curently have in OpenCPN that provides all muxed data GPS, AIS, Active Navigation etc. and is consumed currently by various devices.

Would you expect this to be a reasonably plug and play affair. Any gotchas or tweaks you can share. We will need to probably work out how to filter input and outputs so we can ensure we get only what we care about and send only what is needed out to both the AP and the Network UDP stream. We currently send it to the broadcast address or in our case 192.168.0.255.

I worry about USB assignments between reboots. All devices are connected via a USB3 hub.

I guess we can easily go back to the OpenCPN nav if all does not work.

We have a PINAS also onboard that runs an EMBY server serving all of our TV Shows, Movies and Music collection to the boat devices. 3 TV's with Amazon Fire TV sticks. It is essentially a fairly simple Ubuntu 22.04 server build with extensions for the 4 x sata SSD card. It has pretty low utilisation even when streaming to multiple devices. Can your AVNAV server be used on that server do you think? This would allow us to have one less device and potentially boot form and use the SSD for much faster storage than the SDCARD.

Anyway thanks for all the hard work on this. Happy to keep feeding back our experience.

Cheers
Spart