Onderwerp: Seatalk1/N0183/N2000 integratie zonder multiplexer

hihi NEE. Ik ben te "heel eenvoudig" daarvoor

Baasklusje schreef :
Dat is zeker waar en het inregelen van er al dan niet softwarematige Multiplexer
is projecttopic waardig. Er kan bijzonder veel, maar je kan er ook makkelijk een zooitje van maken. Ik denk dan ook dat zeker de helft of meer van de mensen met een multiplexer daar bij lange na niet uithalen wat er in zit.

Effies schreef :
En de basis van SignalK is NPM, die is mogelijk ook erbij betrokken.

Voorgaande verhaal is typisch een "eenvoudige" Windows applicatie. Klik en Play.

Men snapt niet dat je kaartplotter navigatie software en de data verwerking het beste kunt doen in een aparte data server met in- en uitvoer in allerlei formaten en naar allerlei apparaten.

Server data toepassingen, ook in het groot, draaien veelal op Linux en los van andere applicaties.

Hopelijk gooit een Win10 update de zaak niet in de war. Met een eenvoudig optisch kaartje had je het Seatalk 1 netwerk ook nog kunnen invoeren in de SignalK server.

Bram

brambo schreef :
Ik vind het fantastisch, dat Klik en Play! Ik heb absoluut niet de behoefde een SignalK demonstratie aan boord te gaan gebruiken.

brambo schreef :
"Het beste" is zo eenvoudig mogelijk en zo complex als nodig lijkt mij. Voor wat ik hier wil hoeft het echt niet complexer. De praktijk is dat ik dit in een paar uur aan de praat heb en snap wat er gebeurd. Met SignalK, zeker onder Linux zou dat zeker niet het geval zijn.

Dit is dan ook een projectdraadje voor een "heel eenvoudige" oplossing bereikbaar voor "heel eenvoudige mensen"

Graag on-topic blijven.

Laat de "eenvoudige" watersport mensen eerst het draadje maar eens goed doorlezen alvorens deze "eenvoudige" toepassing te gaan installeren.

Veel plezier ermee.

Bram

brambo schreef :
Dat 'men snapt niet' schiet mij toch even in het verkeerde keelgat, Bram.
De data in dit geval (de bron) is in de formaten van NMEA183 en N2K.
Tussen die 2 op en neer converteren is een fluitje van een cent. Er zijn kleine doosjes voor te koop. Die pakken ST1 en passant ook even mee.
En dan is er nog maar 1 soort data om te processen in een PC-applicatie: NMEA183.
Niet geheel toevallig gebruiken vrijwel alle PC-toepassingen (navigatie etc etc) NMEA183 voor hun input (en output, naar een AP bijvoorbeeld).

Native Signal K sensoren bestaan niet. Dus ook Signal K moet eerst converteren, van NMEA183 of N2K of ST1 naar een intern formaat (wat jij de data server noemt).

Die data moeten dan weer uitgeserveerd worden, we willen ze zien, immers.
Displays op bootjes doen dat met ST1, NMEA183, N2K en nog wat proprietary formaten. Niet met Signal K. Dus opnieuw converteren, uit de data server naar, tsja, naar een formaat waar die data eerder (bij de sensor) al aanwezig was: ST1, N2K, NMEA183......

En Signal K kan ook een HTML-lezer (browser) aansturen. Maar dat is een fluitje van een cent.
Als ik me 3 dagen kwaad maak kan SailingPD ook een webserver hebben en alles (over UDP of TCP) de lucht in schieten naar elke browser in de buurt. Over het hele internet, met TCP.
Dat is allemaal geen rocket science. Maar er zit niemand op te wachten

Komt bij dat de formaten in Signal K (JSON) zo ongeveer 600 keer meer bytes nodig hebben als (bijvoorbeeld) in NMEA183. Dat heeft Meindert Sprang hier al eens laten zien.
Geen punt, datacommunicatie is snel genoeg, maar je krijgt er bloatware van 20.000 files en 200 Mb van, zoals NV zei. En waarom? Om NMEA te vertalen naar NMEA.... zodat we kunnen zien wat onze sensoren hebben gemeten......

Het was mijn vak he, ICT strategie en architectuur

De oplossing van NV is uiterst simpel en robust.
- Vesper als mux (dat ding is er toch en muxen kan hij ook)
- Conversies (ST, NMEA, N2K) door een standaard apparaatje.
- Windows op PC met eeuwenoude technologie die altijd zal blijven: COMpoorten!

OpenCPN had hij al, SPD kan er zo bij (en is niet kritisch om veilig te kunnen varen, wél nodig om hard genoeg te varen )

Zero risk, geen bloatware. Wat wil je nog meer!

Een mooie analyse Baasklusje.

Ja, maar toch vergeefse moeite, vrees ik. Ik het ditzelfde al een paar keer richting brambo geventileerd. Tevergeefs.

Daarnaast is het weergeven van dit soort data in een browser gewoon afzichtelijk, natuurlijk. Maar dat is een kwestie van smaak.

Ha, die Baasklusje kan na 3 dagen arbeid hetzelfde doen wat al standaard in SignalK zit.

Dat het wat meer ruimte in beslag zou nemen is er inderdaad bij een ouder systeem een hinderpaal. Echter met moderne snelle systemen met snelle software en grote opslag mogelijkheden voor een prikje, is dit geen enkel probleem.

Jammer, want SignalK is het "zwitserse" zakmes voor de data communicatie.

Waarom denk dat Damen, Fincantarie en andere werven aan gezamelijke applicaties werken in het SignalK formaat ?

Instrumenten op een beeldscherm of draadloos op je Ipad, GSM telefoon of over het internet.
Dat is pas 2021.

En vooral geen gaten zagen op je kostbare boot voor allerlei klokjes. Gaten waar je later erg veel spijt van krijgt als het niet meer werkt. De klokjes verkopers prijzen die dingen nog steeds aan.

Kijk maar eens in moderne voertuigen. Waar zijn de klokjes ?

Groet,


Bram

Kunnen we het hierbij laten? Ik zou het jammer vinden te moeten modereren...

brambo schreef :
Zoiets?



Dat kan prima zonder Signal K.
Dus je argumenten (beeldscherm, draadloos, internet) hebben niets met Signal K te maken....
'Geen gaten zagen' is niet een heel sterk argument pro SignalK
Gaten zaag je om dingen goed in vast te zetten op een bewegende boot....

Sorry NV, post net gekruist. Ik zal ophouden. Maar dat Signal K.....

Geeft niet.

Nu dwaal ik ook een beetje af, maar het is mijn draadje en ben voorlopig toch klaar tot ik de boot heb.

Ben de polars aan het voorbereiden. Ik ga er 2 maken: een met spi en een zonder spi.

Omdat de ruwe data uit de ORC Speed Guide best wat gaten liet vallen die bij (in Excel, handmatig) lineair interpoleren toch wat al te recht werden, heb ik de plaatjes van de polar's geschaald en Visio gezet. Hulplijnen elke 5 graden. Nu kan ik ook de nogal sterk gekromde curves bij ruime koersen mooi sampelen. Ik ga dan geen nullen invullen in de SPD polar tabellen bij koersen < UD maar echte data.

Hier voorbeeldje voor TWD= 6 kn. Het eind van het rode lijntje leg ik op het punt dat ik wil meten en de lengte van dat lijntje heeft de dimensie knots...



Dan kan ik die koersen ook gewoon varen zonder dat een apparaat "TOO TOO TOO LOW" gaat roepen. Wel even ouderwets handwerk, maar levert een mooi verloop onder zonder gekke rechte stukken:

Je zou ook voor de hoeken buiten de UA en DA de te varen snelheid nodig voor de beste VMG in de polar kunnen zetten.
Zie pag 12 en 13 van de manual.
Een TWA van 0 (of 180) krijgt dan als snelheid de VMG van de beste UA of DA.
Alle hoeken tussen 0 en UA (en 180 en DA) dan (met cosinus) iets meer dan de VMG.
Eindigend bij de V@UA (of V@DA) als je bij de DA of UA bent in de polar.
Als je dan te hoog of te ruim vaart blijft er een performance-percentage in beeld, dat dan weergeeft hoe goed je het doet vergeleken met de optimale UA of DA. Kan je zien of knijpen of te ruim afkruisen beter is

Dat was het idee dat na lange discussie over "wat daar te doen" van Menno kwam toch? Dat ben ik aan de UA-kant van plan. Aan de DA kant is gewoon data beschikbaar. Grappig trouwens, dat het VPP bij plat voor de wind varen een helling berekend! Zal komen door onbalans tussen grootzeil en spi?

Dat was dat idee ja! Een prima idee!

Voor de DA data beschikbaar? Iets meer wel, en voor de wind zeilt makkelijker dan met TWA nul....
Your choice!

Een klein beetje helling heb je al door het gewicht van 1 bemanningslid....
Ik kan het aan boord nu zien (EV1, SPD). Als ik (zonder wind) SB aan de kaartentafel zit: 1 graad helling.
BB op de bank: 1 graad helling. Staan in het midden: 0 graden....

Het VPP zegt bijna 8 graden helling, plat voor de wind bij 16 kn TWS en grootzeil en genua!

Rare boot zo'n Grinde

Sturen geeft natuurlijk ook helling, en voor de wind is 'ie vast wat loefgierig.
Ook de wind-uitstroom uit main en spi zal wat helling geven.
Gaat hij lekker van rollen!

Target heel toch? Met dinghy's word ook onder helling voor het lapje gezeild. Wel een uitdaging met een kajuitjacht.



Gepost met de officiële Zeilersforum-app

Je bedoelt dat deze heel geforceerd moet worden om polar te halen en niet het resultaat is van de zeilstand/koers? Er staat niet welke kant op tov de giekstand

Als je sneller zou gaan zonder helling, zou dat in je polar staan. Bij ruime wind moet jij juist proberen je boot zo recht mogelijk te varen, volgens je polar.

Gepost met de officiële Zeilersforum-app

www.google.com/search?q=optimi...igB&biw=384&bih=767#

Gepost met de officiële Zeilersforum-app

Inmiddels klaar met de Speed Guide polars terugmeten en vele getallen intypen. dit levert mooie vloeiende curves op:



De koersen < UA zijn gebaseerd op het laatste datapunt (35 gr) en de VMG die daar bij hoort constant te houden en de bootspenheid terug te rekenen om diezelfde VMG te halen bij TWA<UA.

Nu nog verzinnen hoe ik de datapunten bij 3 en 30 kn wind moet gaan schatten...

Nachtvlinder schreef :
Ik heb 3kts ongeveer de helft van 6 kts genomen.
En boven de 20 kts een fractie meer maar niet veel; geen planeerboot....
En dan een tijdje varen en uit de log van SPD de waarden voor die wind kts halen!
Bouw je eigen polar; beetje sorteren op TWA en TWS.... en dan wat middelen van de waarnemingen, 1 per seconde... .
Dat kan vast met wat leuke Excel-macro's. Ik ga ze niet maken

@NV,
vertel nog eens hoe je dat nu met VSPE doet.....
Ik krijg het niet werkend.

Wat ik wil:
- 1 COM waarop NMEA binnenkomt (een echte of een virtuele van NavMonPC voor een File Replay)
- daaraan gekoppeld iets als een Connector, om data tussen 2 klanten (SPD en WINGPS) op en neer te sturen.

Een Connector kan niet aan een (echte of virtuele) poort hangen (dus ook niet aan een Splitter).
Een Splitter kan niet doorverbinden.

Vertel!

Dus je wilt VSPE ook laten multiplexen?

-Je krijgt iets binnen op een fysieke (bv COM1)
-Wilt deze data doorzetten naar virtuele COM2 en COM3
-als app2 iets schrijft naar COM2, dan moet die data beschikbaar zijn op COM3, samen met de data uit COM1?
-als app3 iets schrijft naar COM3, dan moet die data beschikbaar zijn op COM2, samen met de data uit COM1?
-moet er ook nog iets terug vanuit app2 en app3 naar COM1?

Wil je nog iets specifieker opschrijven wat je minimaal wilt?