Onderwerp: Optimaal instellen van mux?

Als je een mooi lijstje wil zien gebruik je maar opencpn ofzo.
als diagnosetool doe ik het op deze manier.ik ga niet verder dscussieren over de log. het is zoals het is. deal with it.

Voor de tweede reactie, daarom wil ik graag eerst zien wat erin gaat. als diagnose.
Raden naar wat er wellicht fout gaat heeft geen zin. Weet ik uit ervaring.

Baasklusje schreef :
Als niet ict-er is het inderdaad behoorlijk verwarrend als de zinnen gewoon doorlopen. Pas sinds de laatste paar weken begin ik een beetje te begrijpen hoe dat werkt met NMEA sentences. Eerder keek ik er naar en begonnen de lettertjes/cijfertjes bijna letterlijk voor mijn ogen te dansen. Nu ik weet waar een sentence eindigt en waar die begint kan ik zelf wat met het log. Iedere nieuwe sentence op de volgende regel is een stuk inzichtelijker. Het displayen van het "CRLF" zou zelfs al verwarring kunnen scheppen.
In de uitleg die je vind op het internet over NMEA sentences staat meestal niks over "CRLF" Daar eindigt de sentence met de checksum. "CRLF" zou maar weer voor verwarring zorgen.

Koko, het is voor mij belangrijk om alle karakters te zien.

In een opencp nmea debug window, of andere lijstjes in navigatie programma's is het gefocused op juiste data.

Stel dat er een onverwacht karakter 0 binnen komt. Dus niet getal 0 (hex 30 ), maar de hexwaarde 0.
Deze waarde zie je dan niet in een standaard llijst. Deze waarde zal je nu ook zien in mijn log.
Of stel dat er een backspace code binnenkomt. Dan wil je als ict'er niet dat deze dan de vorige karakter in de log wist en zichzelf niet laat zien!

Dus ik wil alle karakters zien, en de abnormale karakters als hex waarde.

Tenslotte, ik kan ook niks wijzigen aan de manier waarop gelogd wordt. Als ik dat al zou willen, maar dat wil ik niet.

Aha Chris,
Die overweging snap ik. Als programmeur heb jij die info nodig. Dat maakt het begrijpelijk dat je het zo houdt.
Ben onderweg naar de boot. Effe de natte spinaker verleggen

Koko.... waar haal je toch de tijd vandaan..?

roozeboos schreef :
Dat ik ermee moet dealen is geen probleem. Ik lees binair, octaal, hexadecimaal, en interpreteer naar wens als ASCII, EBCDIC, binair, Decimal en zelfs Packed Decimal, en dat alles zonder bril

Maar het moet ook begrijpelijk zijn voor leken-gebruikers (als koko).
En dan is het door elkaar gebruiken van een ASCII-interpretatie en hexadecimaal weergegeven bitwaarden wat verwarrend.
Nodig is dat niet. De log bevat ongetwijfeld alle bits. De displaysoftware zou er naar keuze binair, octaal, hex of asciii van moeten kunnen maken.
Dan mis jij nooit de echte binaire waarden, en een leek kan het toch lezen.

Wat betreft de backspace uit je andere post: dat kan idd heel vervelend zijn.
Ooit (1972) met een DEC-PDP15 gewerkt waar het inleesprogramma voor ponsband mijn typefout en de backspace erna gewoon opnam in de filenaam als characters.
Het volgende programma (een editor) las bij het willen openen van de file de backspace wél als backspace... en kon dus de file nooit meer vinden

Voor de jongeren onder ons die niet weten wat ponsband is: hier een plaatje van een handponsje, waarmee je foutjes in de data op de ponsband kon herstellen. Eerst een heel dun stripje aluminium tape over de foute gaatjes, en dan de juiste gaatjes weer open prikken. Dat was nog eens automatiseren
Kan iemand even lezen wat er op de ponsband staat? Het zal wel in 8-bit ASCII zijn.

joh baasklusje, je krijgt gelijk van me.
Kunnen we weer verder..

roozeboos schreef :
Je weet niet half hoe blij ik daarvan wordt

Net een heel verhaal op mijn splinternieuwe windowsfoon: colision of weet ik veel. Mooi mijn reactie niet willen plaatsen. Maar goed de aloude Aaifoon sputterde ook

Anyway, net voor ik naar mijn werk ga dus op de boot geweest.
Diverse logjes en experimentjes gedaan. Het komt er op neer dat met de performance functie uit het RMB bericht correct doorkomt en bijv Navmonpc daar direct de juiste waypointgegevens mee laat zien.
Op de seatalkbus gaat bijna helemaal goed, alleen de waypointnaam komt nu niet door. Y werd C en WV12 werd 12 C. Xte, dtw en btw kwamen wel goed door.

Het is gelukt om de gps via de RS233 poort aan de laptop te hangen en Hterm een logje te laten draaien.
Vanavond laat heb ik tijd die te posten.

Edit: ik kan het niet verklaren, maar tijdens de "live" logjes kwam het RMB bericht gewoon door, ook via FransonGPS. Wellicht dat ze pas wegvallen bij het opnieuw afspelen van het Franson log. Dat moet ik nog even onderzoeken.

Zoals beloofd hier stukjes uit de logjes geknipt. Ik heb de data in het RMB bericht na gekeken met wat ik zag op het scherm van de Furuno. Dat klopte allemaal.
Zowel Franson als Navmonpc doen niets geks met de data.
Tijdens het "live" (dus niet een log van Franson opnieuw afspelend) nakijken kwam er ook een RMB bericht binnen bij Navmonpc, maar liet de gegevens niet zien.
Nadat ik de Performancefunctie uit had gezet kwam de data niet alleen binnen, maar werden deze ook getoond. Het lijkt er dus helaas echt op dat het ombouwen van de waypointnaam naar Performance niet helemaal goed gaat. Wel naar Seatalk, maar niet naar NMEA.

Hier de logjes. De Waypointnamen in de GPS waren Y of WV12. De Furuno kan 6 karakters kwijt. Dat zie je ook terug aan de lege posities/spaties in het RMB bericht.

Log FurunoGPS rechtstreeks aan laptop (Hterm) Waypointnaam in GPS is: WV12
$GPRMB,A,0.00,R,START ,WV12 ,5253.726,N,00506.458,E,39.8,345.5,0.0,V*77
$GPBWC,111630,5253.726,N,00506.458,E,,T,344.5,M,39.78,N,WV12 *20
$GPGLL,5215.2889,N,00522.8955,E,111631,A*23
$GPGGA,111631,5215.2889,N,00522.8955,E,1,10,1.7,0,M,37,M,,*48
$GPVTG,,T,13.8,M,0.0,N,0.0,K*5A
$GPZDA,111631,25,04,2016,-2,0*64
$GPRMC,111631,A,5215.2889,N,00522.8955,E,0.0,14.8,250416,1,E*59
$GPRMB,A,0.00,R,START ,WV12 ,5253.726,N,00506.458,E,39.8,345.5,0.0,V*77
$GPBWC,111631,5253.726,N,00506.458,E,,T,344.5,M,39.78,N,WV12 *21

Log Alle instrumenten aan MUX, Performance aan, (Hterm).
$GPRMC,104138,A,5215.2842,N,00522.8956,E,0.1,354.0,250416,1,E*69
$GPRMB,A,5.53,L,START ,000F,219.694,N,00513.246,E,7.4,306.8,0.0,A*36
$GPGBS,104140.00,0.9,0.5,1.6,,,,*4A
!AIVDM,1,1,,B,13aI;v@P01PHMa`N29j8i?w>25BT,0*1E
$AIMWV,332.4,T,004.3,N,A*32
$SAVHW,,T,194.0,M,0.0,N,,,*2C
$SAHDG,196.0,,,,*55
$GPGLL,5215.2839,N,00522.8956,E,104139,A*20
$GPGGA,104139,5215.2839,N,00522.8956,E,1,8,2.0,11,M,37,M,,*46
$GPVTG,,T,353.1,M,0.0,N,0.0,K*64
Log Alle instrumenten aan MUX, Performance uit (Hterm)(Waypoint naam in GPS is: Y)
$GPRMB,A,0.00,R,START ,Y ,5219.694,N,00513.246,E,7.4,306.8,0.0,V*3C
!AIVDO,1,1,,,B3aL>PP0086::C7NJ2hDgwpUoP06,0*6B
$SAVWR,51.5,R,3.8,N,,,,*67
$SAMWV,51.5,R,3.8,N,A*15
$GPGBS,110849.00,0.6,0.4,1.2,,,,*45
$GPMWV,052.6,T,003.7,N,A*29
$SADPT,0.7,0*4B
!AIVDM,1,1,,A,13`jc`@P0v0H4UfN0uSa?gwR0aMD,0*18
$SAVHW,,T,196.0,M,0.0,N,,,*2E
$GPGLL,5215.2872,N,00522.8950,E,110849,A*22
$GPGGA,110849,5215.2872,N,00522.8950,E,1,8,2.0,3,M,37,M,,*77
$GPVTG,,T,6.0,M,0.0,N,0.0,K*66
!AIVDM,1,1,,A,83aGsWhj2d<dtu<Md0O@F3W@4>00,0*60
$GPZDA,110849,25,04,2016,-2,0*64
$GPRMC,110849,A,5215.2872,N,00522.8950,E,0.0,7.0,250416,1,E*62


Ik hoop dat er voldoende info is om een goede analyse te kunnen maken.....

is het goed als ik daar morgen even naar kijk?

roozeboos schreef :
Haha, tuurlijk Chris. Er vallen nog steeds geen dooiuh

Ik ben al heel blij dat er toch weer wat meer duidelijk wordt.

grappig, het gaat hier ook fout.
Lijkt erop dat ik een fout heb gemaakt in de code.
Kan me dat eigenlijk niet voorstellen.

hoe zei cruijff dat ook maar weer , voordat ik een fout maak , maak ik m niet?

Law 1: Every program can be optimised to be smaller.
Law 2: There's always one more bug.
Corollary: Every program can be reduced to a one-line bug.

nou hij doet het alweer.
dat is weer 1 bug minder


The other day, I had a chance encounter with some programmers who actually prefer little-endian architecture. It was too weird. When counting to hexadecimal one hundred, they insisted on starting at 1 and ending at 0001.

sw update staat online koko.
www.star-tracking.com/documenten.html

roozeboos schreef :
Dat is top Chris!

Als die on line is ga ik zsm naar de boot. Ben heel nieuwsgierig

Heb je het RMB bericht nu zo herstelt dat de positie goed doorkomt bij Performance aan? En gaat de vertaling naar Seatalk nu ook goed, waypointnaam bij Performance uit?

ja de positie is nu juist. Het eerste getal viel weg inderdaad.
Omzetten naar seatalk kan ik hier niet controleren, heb hier even geen seatalk repeater.
Ik zal dat aan boord controleren. en als het fout gaat proberen te corrigeren aan boord.
neem de software mee.
Tijd zat tijdens de 50 myls

Als je me software mailt, kan ik kijken of het nu ook goed gaat in de pc (of Navmonpc de nieuwe RMB lust met performance aan). Dat zou ook mooi zijn.

staat op mn website hoor

Ah, dan kijk ik straks nog effe misschien.

En Koko,

Voortgang geboekt?
Ben benieuwd heb namelijk bijna de zelfde opstelling alleen geen Furuno maar een MLR GPS.
Verder geen plotter en maak ik gebruik van OpenCPN.

Ik zit zelf ook nog steeds te knoeien met wat de beste software configuratie nu is.
Zo valt bij mij nu geregeld BTW naar 0.

Richard

Ik heb de laatste aanpassing in de software nog niet kunnen testen. Met een beetje mazzel heb ik daar vanavond gelegenheid voor.

Hoe ziet jouw installatie er precies uit? Welke soort data komt er binnen, via welk protocol en op wat voor soort repeaterdisplay maak je het zichtbaar?
Heb je al eens ee logfile opgeslagen en bekeken wat er binnenkomt aan data?

Koko,

Ben morgen weer aanboord zal ff lijstje maken dan wat er allemaal draait.

ja, wat koko zegt inderdaad.

Eerst maar even kijken wat er allemaal de mux binnenkomt. Daarna wat eruit gaat.