Onderwerp: Optimaal instellen van mux?

In verschillende draadjes al naar voren gekomen: ik bezig het digitale gedeelte aan boord te optimaliseren en dat lukt net niet helemaal. Ik weet dat er inmiddels aardig wat bucks zijn opgelost in de Roosmux, maar kom er ook achter dat ik als eindgebruiker en "programmeur" wel eens een buckje schiet. Dat laatste lijkt steeds meer het geval, dus richt ik me eerst maar eens daar op.

Eerst even het beeld van wat er aan digitale info aan boord is:
Een seatalk netwerk, met log, diepte, wind als gevers, een Graphic, een ST70 en soms een C80 plotter als repeaters. De C80 kan ook data geven, maar dat gebruik ik momenteel niet.
NMEA 0183 gevers zijn een Furuno GP32 gps en een Ocean Sat AIS transponder.

Op de USB hangt een netbookje dat vooralsnog gebruikt wordt als repeater. FransonGPS (betaalde versie) fungeert als verdeler van alle data en kan desgewenst een log maken van de inkomende data.
Ook hier geldt dat het netbookje ook als gever zou kunnen dienen, maar dat gebruik ik momenteel niet.

De Mux zelf dient ook als gever: hij genereert in elk geval Performance data en zet die op het Seatalk en NMEA netwerk. Daarvoor gebruikt hij het RMB bericht, waarin hij de waypointnaam wijzigt in performancedata. Verder vertaalt de Mux Seatalk naar NMEA, en dat ziet er op dit moment goed en netjes uit. De data komt correct over.

Wat is er al bereikt:
Alle repeaters, zowel seatalk als nmea en usb ontvangen data.
Alle gezonden data komt door, bij de configuratie waarin Furuno op ingang 1 en AIS op ingang twee zit.

Wat is de wens: ik wil dat er sprake is van een back up. Daarom zijn er twee gps-en: de furuno en de ais aangesloten op de mux. Als de een wegvalt moet de ander overnemen. (Er zijn nog meer back up systemen aan boord, maar die vallen buiten de scoop: niet aangesloten op de mux).
Ik wil de performance functie altijd kunnen gebruiken.
Ik wil de AIS data zichtbaar kunnrn hebben op plotter en op laptop.


Wat gaat er mis: bij bovenstaande configuratie van de mux krijg ik continu een alarmmelding in WinGps dat ik in aanvaring kom met mijn eigen schip. Het RMC bericht van de AIS wordt geblokkeerd (tot de gps weg valt).
Wanneer ik de gps verwijder komt de back up in werking en behoud ik een positie op de laptop, maar ben ik de performance kwijt, naast de andere data die meekomt met het RMB bericht. Ook blijft mijn eigen schip met naam en toenaam in beeld verschijnen. Dat laatste vind ik heel apart.

ik vermoed dat er dubbele berichten binnenkomen, maar welke? En welke zijn schadelijk/ verstorend op de werking van de apparatuur?
Een beschikbare workaround is niet de mux, maar de Graphic de nmea van en naar seatalkvertaling te laten doen, maar ben ik dan niet de performance kwijt?

Een complex verhaal. Is er een gangbare werkwijze om de oorzaak in kaart te brengen? Of wil ik iets wat niet kan (altijd automatische back up bij uitval gps) in combinatie met de mogelijkheden?

koko schreef :
Dat alarm kun je in WinGPS toch wel onderdrukken? Ben je wel alle andere AISalarmen ook kwijt
Er is ook wel een vinkje ergens in WinGPS dat regelt dat je geen alarm voor jezelf maakt. Even een uurtje zoeken

In de backup-GPS zal de mux wel de SOG missen en dus geen performance kunnen uitrekenen. Geeft die backup-GPS wel een VTG?

Waarom is het apart dat de Gotcha in beeld blijft op de AIS? Dat wil je toch ook?

Er is vast ook een risico op allerlei loops in berichtenverkeer. Heb je nog ergens een draadje aan een Multi of Graphics hangen aan de Nmea Out?
Of een andere loop? Kan haast niet met maar 2 NMEA-talkers....

Verder is het natuurlijk een heel goed idee om de NMEA -> Seatalk door een Raymarine instrument te laten doen Of je dan Performance kwijtraakt, denk het wel, tenzij die RMB ook in NMEA wordt uitgestuurd door de mux (en er geen echte RMB uit een GPS of AIS komt).

ik meen dat dat iets was met een ais bericht.
het NMO. je AIs geeft posities door van anderen (NMI ), maar ook die van jezelf.

Ik dacht ik ooit iets had ingebouwd hiervoor, maar dat moet ik dan even nakijken.

Ik denk dat ik eerst maar eens op zoek moet naar loopjes of dubbele berichten. Ogenschijnlijk draait het goed, maar het lijkt er op dat er naast positieberichten uit het RMC bericht nog andere berichten met positie zijn. Dat is dan geen zuiver dubbel bericht (zeg 2 x RMC) maar wel verwarrend.

Op dit moment geen nmea in of uit de Graphic, om dubbele berichten te voorkomen. Is een optie die ik later wil bekijken mocht dat nodig lijken. Dit hele geintje is begonnen vanwege performance, dus die wil ik behouden.

Ik heb al gekeken in Wingps, maar nog niet gevonden dat ik mijn eigen schip als AIS target kan filteren. Nog eens een uurtje aan besteden uiteraard wil ik mijn eigen schip zien gaan over het scherm, maar niet als target. Dat is niet nodig, want tegen mijzelf aanvaren.......dat is me nog niet gelukt

Ik ken de sentences uit de Ais nog niet. Ga ik even op googlen. Wordt nog een interessante excursie zo, door de grotten van het digitale instrumentarium.

roozeboos schreef :
bedoel je AIVDO en AIVDM?

@ koko

In WinGPS kan je "eigen vaartuig" verbergen op [ Instrumenten / AIS / AIS-instellingen ]. Daar staat iets onder het midden zoiets als "" verberg eigen vaartuig". Maar,................dat werkt alleen als je bij [ Bestand / Eigenschappen / Schip ] je eigen MMSI nummer hebt ingevuld want anders weet WinGPS niet wie hij moet verbergen.

Aart

WADnWIND schreef : ja dat.
ik wist wel dat iemand het wel even zou corrigeren..

@Aart: bedankt!
Was al aan het zoeken geweest, maar nog niet erg goed

koko schreef :
Had je al een uur gezocht? Het zit goed verstopt!!

Baasklusje schreef :
haha, Nee, Aart heeft me gematst.

Ergste was dat ik op beide pagina's ben geweest. Een aantal gebruikersafhankelijke data had ik al ingevuld, behalve dus het mmsi en dat vinkje

Vanavond logjes getrokken. Morgen analyseren (om te leren).

Net even de logjes zitten bekijken. Er zitten inderdaad dubbele berichten in van verschillende bronnen.

GGA komt uit Furuno GPS en AIS transponder
GLL ook uit Furuno GPS en AIS transponder
ZDA komt uit Furuno GPS en uit de Mux zelf ( = een gebruikersinstelling, destijds ingegeven om die data ook op de seatalkrepeaters te krijgen. Zou een loopje geworden kunnen zijn.

RMC uit de AIS transponder had ik al gefilterd.

Uit de Seatalkbus komt MWV (2x kort achter elkaar, ik vermoed Wind true en apparent?)
DPT
VHW
HDG
VWR.

Wat me nu o.a. bezig houdt is dat er in meerdere sentences (denk ik dan) een positie verwerkt zit; GGA, GLL, RMB, RMC. (Laat ik de AIS posities even buiten beschouwing). Lijkt mij dat dat niet goed gaat, of maakt dat niet uit als ze allemaal uit dezelfde bron komen? Of kan ik beter sommige berichten helemaal wegfilteren?

Uit mijn (vaste) GPS komen ook GLL, GGA, RMB en RMC, en WinGPS heeft daar geen last van.
De RMC uit de AIS wordt tegengehouden door WinGPS.

MWV: Dat is een interessante.
De layout is:
$--MWV,x.x,a,x.x,a*hh<CR><LF>

---

Field Number:

1. Wind Angle, 0 to 360 degrees
2. Reference, R = Relative, T = True
3. Wind Speed
4. Wind Speed Units, K/M/N
5. Status, A = Data Valid
6. Checksum

Dat roept de vraag op: wat betekent Relative en True... is Relative hetzelfde als Apparent, en True is True? Moet haast wel, en dan kan je aan de R of T zien wat het is.

Je hebt gelijk, het is MWV T of R.

Dan filter ik de gps-gegevens uit de AIS. Mocht dan de Furuno wegvallen komt die data weer terug via het prioriteiten filter. Bedankt!

Ik heb hier een deel van de logfile.

LET OP: voor overzicht heb ik de talker ID aangepast (functie van de software).

FU = Furuno GPS
OS = Ocean Sat AIS
RA = Raymarine

Dan valt er nog eentje op: de GPZDA, die komt uit de mux zelf (ook een gebruikersinstelling, waarin je kan kiezen deze zelf toe te voegen. Die ga ik nu ook uitzetten).

Goed bezig Koko!!

roozeboos schreef :
Dank je. Ik moet zeggen dat ik het ook leuk vind om weer een stapje verder te komen qua begrip en kennis op dit gebied. Nu het netbookje er eenmaal is wil ik dat natuurlijk ook goed kunnen inzetten.

Een mooi hulpmiddel is ook FransonGPS. Die kan de data heel mooi loggen en opnieuw afspelen. Als de mux ge-optimaliseerd ga ik een logje maken met FransonGPS en dan de verschillende software verder optimaliseren.

Ondertussen weer een stuk verder met het inregelen, maar nog niet alles gaat naar wens. Ik kom er niet goed achter waar dat zit.

Op de Seatalk instrumenten komt alles binnen wat ik wil, inclusief de informatie uit het RMB bericht. Zaken als afstand tot WP, Bearing to WP en XTE. De Waypoint naam wordt (zoals ik inmiddels eigenlijk wel bekend acht) omgebouwd tot performance. Ook dat ging gister tijdens de wedstrijd (6 uur) allemaal goed.

Bij de computer gaat het niet goed. Tenminste, als het gaat om de RMB info. De Seatalk info komt goed over, de rest van de info ook

FransonGPS logt alles wat er binnenkomt, maar in dat log geen RMB bericht......?
En dus geen RMB gegevens in Navmonpc. En dat is weer jammer voor de analyse achteraf. En ik vind eigenlijk dat het gewoon moet kunnen werken.

Ik vermoed dat er iets niet lekker gaat bij FransonGPS. Helemaal snappen doe ik dat niet, want de rest komt wel door. RMC, GLL, ZDA, enz enz. Dat maakt dat ik denk dat Franson wel goed is ingesteld bij de poortconfiguratie.

Als ik het RMB bericht bekijk valt er eigenlijk maar 1 ding op: de Noordelijke positie lijkt niet te kloppen. Geen 5, maar 3 of 2 als eerste cijfer. Verder lijkt het alsof er een extraatje aan de checksum zit. Geen idee of dat kan.

Hier een knipsel uit de het log. Het begin van het RMB bericht en een beetje na de checksum.
Kan het zijn dat Franson vanwege een foutje (welk?) het RMB bericht weigert?

$GPRMB,A,5.53,L,START ,000P,219.694,N,00513.246,E,7.4,306.8,0.0,A*36\0Dh\0Ah$GPGLL,5215.2886


Hier nog een prt scr van de instelmogelijkheden van FransonGPS.

$GPRMB,A,5.53,L,START ,000P,219.694,N,00513.246,E,7.4,306.8,0.0,A*36


sentence klopt niet


probleem zit in de voor fake gebruikte to waypoint positie die is ongeldig.

latitude bestaat altijd uit 4 karakters voor de decimaal, (longitude altijd uit 5)

219.694,N moet worden 5219.694,N

laatste A zou beter een V kunnen zijn.


edit zoals ik al eerder opmerkte en Baasklusje nu ook, speel je het log later af dan struikelt de boel op de manier waarop het log wordt weggeschreven, iedere sentence hoort op een nieuwe regel te beginnen, log is zo niet algemeen bruikbaar.

$GPRMB,A,5.53,L,START ,000P,219.694,N,00513.246,E,7.4,306.8,0.0,A*36\0Dh\0Ah$GPGLL,5215.2886

Staat dat allemaal op één regel? Aan het eind van een bericht hoort een CR/LF te staan (ouwe typmachine: wagenterugloop en nieuwe regel )
Die zijn er niet, na de checksum (*36) staan ze wel in ASCII hexadecimaal (0D en 0A), maar je verwacht dat ze worden zichtbaar gemaakt, niet in Hex getoond.Dan een GPGLL, die het volgende bericht is, waarschijnlijk.

Dit bericht bevat zowel positiedata als performancedata. Ik weet niet of dat de bedoeling is?
er zit achtereenvolgens in:
A voor correcte werking
een XTE van 5.53 mijl
de L voor LEFT te sturen naar de Track
het doelwaypoint: Start (koko,kan dat?)
het vertrekwaypoint: de performance van 0,0
bestemminglatitude: 219.694 Dat is heel gek, die 219, dat is op de maan ;-)Bovendien geen 4 posities vóór de decimaal en 2 erachter, maar 3 om 3, dat is fout.
N voor Noord
bestemmingslongitude: 00513.246 Zou kunnen
E voor East
afstand tot doel: 7.4 miles
BTW 306.8, noordwest dus
closing velocity 0,0 kts, dus we gaan niet naar het waypoint...
A voor Arrived at Waypoint

Kortom, deze RMB is een rommeltje.



De normale layout:
RMB - Recommended Minimum Navigation Information

$--RMB,A,x.x,a,c--c,c--c,llll.ll,a,yyyyy.yy,a,x.x,x.x,x.x,A*hh<CR><LF>

Field Number:
1) Status, V = Navigation receiver warning
2) Cross Track error - nautical miles
3) Direction to Steer, Left or Right
4) TO Waypoint ID
5) FROM Waypoint ID
6) Destination Waypoint Latitude
7) N or S
8) Destination Waypoint Longitude
9) E or W
10) Range to destination in nautical miles
11) Bearing to destination in degrees True
12) Destination closing velocity in knots
13) Arrival Status, A = Arrival Circle Entered
14) Checksum

edit: ik zie dat henkvd ook de lengtefout van de latitude noemt.

Thomas,
Het is een stukje uit het logbestand van de mux. Het overgaan naar een nieuwe regel gaat wel goed bij de andere loggers, zoals Hterm of Navmonpc. Ziet er niet netjes uit, gaat verder wel goed gelukkig.

De boot ligt stil, dus snelheid naar waypoint is 0.0. Klopt ook.

De waypointnamen worden door de mux aangepast. Ik moet even aannemen dat de Mux beide namen aanpast. Weet zo niet of mijn Furuno die Start aangeeft of dat de mux dat er van maakt. In de info die ik vond op internet is de eerste naam het startwaypoint en de tweede naam het destinationwaypoint.
De tweede naam is aangepaste waypointnaam: de performance.
Die Bestemmingslatitude vind ik ook gek en klopt natuurlijk niet.
Die A is inderdaad ook gek, want ik was er nog niet. Hieronder de info die ik geplukt heb van internet

RMB - The recommended minimum navigation sentence is sent whenever a route or a goto is active. On some systems it is sent all of the time with null data. The Arrival alarm flag is similar to the arrival alarm inside the unit and can be decoded to drive an external alarm. Note the use of leading zeros in this message to preserve the character spacing. This is done, I believe, because some autopilots may depend on exact character spacing.

$GPRMB,A,0.66,L,003,004,4917.24,N,12309.57,W,001.3,052.5,000.5,V*20

where:
RMB Recommended minimum navigation information
A Data status A = OK, V = Void (warning)
0.66,L Cross-track error (nautical miles, 9.99 max),
steer Left to correct (or R = right)
003 Origin waypoint ID
004 Destination waypoint ID
4917.24,N Destination waypoint latitude 49 deg. 17.24 min. N
12309.57,W Destination waypoint longitude 123 deg. 09.57 min. W
001.3 Range to destination, nautical miles (999.9 max)
052.5 True bearing to destination
000.5 Velocity towards destination, knots
V Arrival alarm A = arrived, V = not arrived
*20 checksum

Edit: ik ga bij tijd en gelegenheid Navmonpc eens laten draaien rechtstreeks aan de mux. Dan zien we wat de invloed is van FransonGps op het RMB bericht.

Franson doet niets anders dan doorgeven.
Navonpc let wel op de sender-id, en accepteert alleen berichten van toegestane senders. Dat kun je ergens instellen. Het verklaart waarschijnlijk het ontbreken van berichten in Navmonpc.

Baasklusje schreef :
Dat dacht ik ook, maar de mux heeft een RMB aan boord, maar die komt niet meer naar voren in de nmea log van Navmonpc en ook niet in Hterm. Dat is er zo gek aan. Franson zit er dan nog tussen.
Ik denk dat we het gaan zien als Navmonpc direct aan de compoort van de mux komt te hangen.

Misschien morgen, anders dinsdag weer verder kijken.

nou,nou, ik kijk ff een avondje niet...

misschien kan koko even kijken wat erin gaat.

Wat de mux doet is het inlezen van het RMB bericht.

dan tel ik het aantal comma's. verwijder de data tussen de juiste twee comma's en plaats de performance daar voor in de plaats. Niets meer ,niets minder.de rest blijft dus onaangeroerd. (of ik moet een programmeerfoutje maken)
En voor nachtvlinder: de checksum wordt opnieuw berekend en ook vervangen.

Het zou kunnnen, koko, dat er iets mis gaat met de positie. In principe niet, want het werkt normaal gesproken prima.
Om het te kunnen corrigeren voor je is het even het handigste als ik zie wat er precies ingaat.
dus RMB bericht in.
dan kunnen we een diagnose doen over wat er mis gaat.

nb: baasklusje , alles klopt, ook de CR/LF. Alle data die er moet staan staat er.
jij neemt aan dat de log ook meteen naar de volgende regel springt bij CR/LF.
dat klopt natuurlijk niet. Een log logt. En log gaat juist niet mee met de ascii betekenissen van de tekst. de log laat alle data zien zoals die voorbij komt.anders ben je het overzicht kwijt.
De h wordt erbij gezet om aan te geven dat het de hex code is. Denk er maar even over na,het klopt precies.
een nieuwe regel hangt af van tijd. Tijd loopt niet synchroon met cr/lf. vandaar het soms afkappen van een regel midden in een bericht. wat je ziet is de data. Niets meer, niets minder.
precies wat je wil als diagnose. de henkvd quote'niet algemeen bruikbaar' is echt onzin.
juist die lage ascii codes wil je als hex code zien, en niet afhandelen als ascii codes.
stel je krijgt een new page code ertussen door, moet die dan een nieuwe pagina aanmaken in je lijst? (geen reply svp)



de positie afhandeling gaan we oplossen hoor Koko!
Ik ben meer van oplossingen zoeken, ipv eindeloos geneuzel over hoe erg het wel niet fout is.
beste stuurlui, dat idee.
sorry, ik ben een oost Grunninger van oorsprong, die zegt t gewoon.

Ik ga kijken of ik het bericht rechtstreeks uit de gps kan halen. Zonder tussenkomst van mux of Franson naar Hterm. Dat lijkt me de zuiverste manier. De Furuno heeft een RS232 poort en ik heb een RS232 naar USB converter, moet lukken. Nog nooit gedaan, maar eens moet de eerste keer zijn.

Ik zal ook kjken of Navmonpc rechtstreeks aan de mux wel iets kan met het nu gezonden RMB bericht, met en zonder Performance berekening.

Chris, in Amersfoort denken we dat het analyseren van wat er niet goed gaat bijdraagt aan de oplossing en ben blij te kunnen bijdragen aan de continue verbetering van de Mux.

roozeboos schreef :
De log zelf is natuurlijk niets anders dan een reeks nullen en enen.
Waar we naar kijken is een display van een interpretatie van die nullen en enen.
Die interpretatie is deels als ASCII en deels als hexadecimale getallen.
In een display van de interpretatie zou ik dat niet doen; dan zou ik hex 0A en 0D als CR/LF laten zien, fysiek, door naar het begin van de volgende regel te gaan.
Je zou ook "CRLF" kunnen displayen.
Door de mix van interpretaties (ASCII en hex) wordt het volgens mij verwarrender dan nodig, en kan het onduidelijk zijn wat er nu precies gebeurd is.
Je moet nooit meer verwarring scheppen dan de hoogst noodzakelijke (in IT dan)
just my two cents, als amsterdammer

Wat betreft de verdwenen meest-significante positie in de latitude: het is wel erg toevallig dat dat precies NA de ingevoegde performance is.
Eén byte teveel overschreven?