Onderwerp: Toepassing van AVnav

Reading O-Charts License carefullyso it is about number of installed copies and not about number of display devices. Otherwise the display of O-Charts in OpenCPN via VNC would not be allowed.

Moreover, @wellenvogel works in close contact with O-Charts people and everything was agreed beforehand. We thank O-Charts for such a wonderful cooperation.

BlackSea schreef :
Hi, could you elaborate a bit more? I use AVnav on my smartphone with Android13 and have a W11 desktop (nuc) at home but prefer to keep it there. Linux, RPI and all the operating systems discussed here are not my cup of tea to be honest... but I like AVNav more than Opencpn on my phone and would like to use it with "official" charts.

it is planned, if Android device is already licensed in o-charts store, to continue using this license for the same device with AvNav. Or am I somehow misunderstanding your question?

Thank you, that was indeed what I meant. So if I use 1 license key for my smartphone I would be able to use ochart (offline) and the maps are loaded on my phone. Another question is if I can use my phone as a server (wifi hotspot) and allow a passenger to connect just like is done with an onboard rpi/mini pc at other boats

you can already use something like this
wellenvogel.de/software/avnav/...android.html?lang=en

Een goed werkende en veelzijdige multiplexer voor Linux/RPI is Kplex.

www.stripydog.com/kplex/

7mtr schreef : I think all the problems presented here in this thread, stem for the fact that I run AVnav on my desktop, with OpenCPN right next to it. My eventual implementation would be on the Pi (cheap, solid, low power consumption) through image-installation. My expectation is that I encounter NONE of the presented problems.

When I've made the step to the Pi, I'll you eport back ofcourse. Maybe you can then reconsider your stance. Or at least have some honest background info about AVnav on a pi.

BlackSea schreef : As I already stated, whenever I hit 'apt update' I'm welcomed whith a huge nummer of errors:


This stems from the modification of the package-source (as you suggested). I can see, not all packages in the debian/buster PPA are avialable in ubuntu/jammy, thus the errors.

I do not have jammy-backports active (yet). But before I do that, I want to get rid of the errors shown above, right now my system is a bit untable.

I can see port 34567 is up and running when AVnav is active. So what you say I can tap into the NMEA-bus trough this port, and that would be fantastic! One of my idea's is to make an AIS-alarm on the Pi (by using the pins as output), apart from AVnav. So when a ship comes near to me, say 5 miles, a very load audible alarm goes off. This is probably already covered in AVnav itself, but I do not want to be solely dependent of AVnav and/or the browser-device which connects to the AVnav-server.

Have you any documentation or examples concerning the use of this NMEA-port?
I'll try this. The result should be that OpenCPN is not blocking GPS for AVnav anymore

Tested and this works beautifully!

Now OpenCPN does not block AVnav for GPS-usage anymore, they are working through the same hardware and you can use both OpenCPN en AVnav on the same device, using common hardware like the GPS. So AVnav is apparantly a multiplexer which OpenCPN can use.

Eeuh het is andersom, omdat avnav de gps al gebruikt kan opencpn heb niet meer gebruiken.
Nu stuurt Avnav de data door naar Opencpn, dat kan zo.
Het kan ook andersom je laat opencpn de GPS gebruiken en laat opencpn de data doorsturen, ook daar kun je in verbindingen multiplexen, routen, filteren etc.

I have suggestedand there is nothing about "contrib"
Compare what is and what should.
I have good news and bad news.
The good: yes, it is possible to set different alarms. e.g. for anchor or gps.
See in wellenvogel.de/software/avnav/...figfile.html?lang=en the info about AVNAlarmHandler

The bad: AIS alarms are currently generated on the frontend side (display device).

Issue and possible workaround: github.com/wellenvogel/avnav/issues/82

Zeilprutser schreef :
In mijn wereld is een multiplexer een ding (hard of soft) dat data van meerdere NMEA-bronnen kan ontvangen en die stromen dan combineert in een uitgaande stroom,voor een toepassing die meerdere soorten data gebruikt (GPS voor positie, instrumenten voor wind, snelheid, diepte, AISontvanger voor AISdata).

Aan de documentatie te zien kan AvNav op Pi meerdere bronnen aan.
Kan OpenCPN dat ook??
Of moet daar iets voor (hw-mux, Signal K) dat de multiplexing doet?

VegaMan schreef :
Ik heb niets tegen een rpi of w11 pc maar wil het gewoon niet aan boord. Een Android smartphone en tablet moet voldoende zijn.

In fact opencpn can act as a multiplexer. Only unfortunately stability of the thing leaves quite a few wishes open. Has happened to me several times in the middle of the pond that OpenCPN had crashed (eg because of map display error) ... what happens then? Then all attached devices are also dead.
I actually do not want to start Flame War monolithic software architecture against server/client.

BlackSea schreef : Yup, mixing server-tasks with a complete GUI is from a architectural viewpoint not the best solution, to say it mildly hahahhaaha
7mtr schreef : Aha, snap jouw standpunt, in eerste instantie was dat ook mijn standpunt, 1 device to rule them all, vanuit het KISS-principe.

Heb daartoe een 'rugged' tablet die ik in de kuip kan en wil toepassen. Kwam er al snel achter dat, wil je met o-charts werken icm een dongle, dat dat eigenlijk niet kan. Alleen in theorie kan het met OpenCPN, maar je hebt dan een dongle aan je (waterdicht) tablet hangen wat zelf niet waterdicht is, dat kun je dus afserveren. AVnav ondersteunt o-charts op de app (nog) niet, dus daar hoef je überhaupt niet na te denken over o-charts in de app.

Met AVnav als client-server wordt het een heel ander verhaal. De server met dongle zit dan veilig en droog in de kajuit. Elk device, al of niet waterdicht kan daarnaar connecten. Datzelfde verhaal zal gaan gelden voor een AIS-dongle/kastje, ook die wordt (binnen) aan de AVnav-server gehangen. Nu zijn er wel AIS-oplossingen waarbij de info via wifi verzonden wordt die je dan weer op je device (foon/tablet) kunt ontvangen, maar dat vind ik persoonlijk een halve oplossing want het ocharts/dongle probleem heb je daarmee niet opgelost.

Echter zal ik ook een of meerdere android-devices (tablet + foon) gebruiken als backup, voor als de server uitvalt; op het tablet kan ik dan kiezen voor de server of voor de app. Binnen de app kan ik dan gebruikmaken van (gedownloade) kaarten van openseamap (o-charts vervalt vanwege de dongle). Ja, het is een thuiskomertje, maar het is beter dan niks. Eventueel zou ik, in nood, zelfs het AIS-signaal nog kunnen doorlussen naar zo'n device.

Hiermee denk ik een volledige oplossing te hebben die tevens zeer robuust is omdat er backup is ingebouwd. Niet al je eieren in 1 mandje leggen....

VegaMan schreef :
Architecture by itself does not determine stability.
Lousy software does, be it cliënt or server.

BlackSea schreef :
What happens when the AvNav multiplex server crashes?
You still have a beautiful map on your cliënt screen but no idea about your actual position, I assume?

1) Has never happened to me
2) Source code of backend is very robustly designed
3) Just in case I have 2nd device with AvNav server

VegaMan schreef :
The forum and every other website out there would like a word...

AvNav's GUI is handled mostly client-side, the server itself only serves the map tiles and handles any widget click events. If your AvNav server goes down, then yes, you are left with a pretty GUI on your tablet/phone/other device that doesn't do anything.

Not unlike a Raymarine plotter having a hissyfit and suddenly deciding it's not going to work anymore.

Something about eggs and baskets

BlackSea schreef :
So probably the beautiful cliënt map will freeze

De oplossing om AVnav als een multiplexer te gebruiken ten behoeve van OpenCPN om hardware gemeenschappelijk te benutten is feitelijk puur theoretisch. Want iedereen zal gaan voor óf voor OpenCPN óf AVnav, nooit gelijktijdig, daar is eigenlijk geen use-case voor. Tis mooi dat er oplossing is maar die heeft eigenlijk geen praktische waarde.

Zo kunnen we weer ontopic (Avnav).

VegaMan schreef :
Er is nog andere sw die NMEA gebruikt dan alleen nav-sw......
Een heleboel zelfs.

Baasklusje schreef : Dat was niet het punt. Het ging erom dat je AVnav als multiplexer zou kúnnen gebruiken. Het simpele antwoord is ja. Dat je 1000 en 1 andere mogelijke multiplex-achtige oplossingen hebt is duidelijk maar doet in deze niet ter zake.

Ontopic.

Heb even bekeken hoe je die multiplexer kunt bevragen. In de basis is dat supersimpel: wijs met je browser naar http://localhost:34567. Je krijgt dan alle NMEA-output te zien. Heb (nog) geen AIS-ontvanger, maar neem aan dat ik díe output dan ook ga zien.


(output van de GPS)

Even een scriptje in elkaar klussen om (headless) de NMEA-bus te bevragen en te decoderen en ik heb zo mijn AIS-alarm bij elkaar geprutst. Voor nop eigenlijk.

BlackSea schreef : In the situation where you have AVnav running on a Pi, it is very cheap to have a second Pi on hand as a backup, in case the Pi dies (not very likely but better safe than sorry). If the hardware is not that cheap as a Pi (like a NUC + SSD), one is unlikely (but not impossible) to have such a hardware-backup, due to price.

A second disaster-measure can also be by having a copy (mirror) of the SD-card available. If the SD-card dies, you can have the Pi up and running in literally one (1) minute, just swap the SD's and reboot.

You can than even combine the two and have a Pi + mirrored SD-card ready to use. If anything dies (Pi or SD-card), just swap the complete unit (Pi + card) and again, within one minute you are up and running (again)

De mtbf van een Raspberry is ongeveer een tiende van een redelijke ssd.

BlackSea schreef : This is exactly my point why I want to have a AIS-alarm which is (as far as can be) autonomic, thus not dependent an any display-device.

Baasklusje schreef : Zoals eerder gezegd, heb nu mijn testopstelling al zover dat de GPS-info bij AVnav binnenkomt en via de multiplexer wordt doorgegeven aan OpenCPN, dat werkt dus prima.

Ben van van plan ook een AIS-dongle aan te schaffen die dan sowieso voor AVnav moet gaan werken. Als het goed is, is die info dan ook tegelijkertijd voor OpenCPN beschikbaar, via dezelfde multiplexer-connectie; aan de kant van OpenCPN hoef je dus NIETS extra in te stellen. En kun je die info (GPS + AIS) ook via een losse web-client opvragen en decoderen. Maar goed, het blijft theorie, zien is geloven hahahaha