Onderwerp: Incorrect RMC bericht! Hoe kan dit?

roozeboos schreef :
Dankzij je handige link naar eerdere firmware versies heb ik nu een volledige roll back kunnen uitvoeren. Het een en ander werkt weer zoals het was toen ik vertrok. Met een Raspberry Pi die het zware werk op zich neemt. Misschien niet allemaal galvanisch gescheiden maar ik weet nu met redelijk zekerheid dat er geen berichten verdwijnen.

Je mux op basale functionaliteit testen is redelijk simpel. Stuur met een computer via 3 of drie com-links NMEA logbestanden op de mux af met 38400 baud met 2-4 ms tussen de afzonderlijke berichten. Lees ondertussen op de USB de zinnen terug en controleer de checksum.

Geeft een heel aardig beeld hoe goed het ding presteert.

mooi dat t weer werkt, net op tijd. Welke versie draai je nu?
lengte van berichten doet er ook toe natuurlijk. Ik had gehoopt op een logje.

Gefeliciteerd! Dat moet een enorme opluchting zijn! Gelukt met een beetje van Chris en een beetje van jezelf!

@Chris, ik begrijp niet waarom sommige updates schijnbaar niet backwards-compatible zijn. Ik denk dat testen voor iets de deur uit gaat wellicht belangrijker is dan je denkt: zeker de "super-users" verwachten denk ik niet dat zij de rol als beta-tester onbewust dienen te vervullen, maar rekenen op een robuust en functioneel produkt.

Ter inspiratie: in onderstaande link zie je een voorbeeld hoe een aanbieder van een vergelijkbaar product daar mee omgaat. Komt op mij zeer gestructureerd over; het zijn niet zomaar wat probeersels. Heb gisteren (heel voorzichtig, in de box) voor het eerst een update van de software in m'n kaartplotter uitgevoerd. Daar staat per versie (zijn er maar een paar geweest in 3 jaar - voornamelijk om met de groeiende N2K functionaliteit mee te kunnen) de release notes weergegeven. Met de duidelijke tip om niet te updaten als er geen reden voor is.

Top dat je je zo inspant, zelfs als klanten in een enigszins sjagarijnige bui verkeren! Je gaat nog wel uitzoeken wat en waarom het nu mis ging in 3Noreens's geval?

MiniPlex-3 firmware changelog

niet updaten als er geen reden toe is??? dat geeft ook niet veel vertrouwen..


Als je de postjes leest weet je dat ik echt probeer een fatsoenlijke log te krijgen van Gary. Dat zou de snelste manier zijn om het op te lossen, als ik het hier kan nabootsen.

roozeboos schreef :
Waarom zou je wél updaten als er geen reden toe is?

In mijn geval wordt nu de "SonicHub" functionaliteit ondersteund, een van de latere ontwikkelingen in de N2K standaard. Ik kan nu m'n multimediaspeler vanaf de plotter bedienen. Vóór die update werd het device niet herkend.

In een eerdere update (die ik dus overgeslagen heb) was er bv een NMEA-logging functionaliteit toegevoegd - daar had ik geen behoefte aan.

Als updates het doel hebben om bugs te verhelpen ipv nieuwe features toe te voegen, ja, dan is het wél belangrijk altijd de laatste versie te draaien. Is dat bij jouw produkt het geval?

Ik update mijn Miniplex 42 als sinds 2003 niet; het kan niet, maar ik heb er ook geen enkele reden voor.
Alles werkt prima, en AIS (op 38k4 bps) gaat buiten de mux om de PC in.

Als er een moment komt dat ik functionaliteit ga missen dan koop ik een nieuw model en dat kan dan weer 15 jaar zonder updates.
Voorlopig zie ik geen reden voor een nieuwe:
- NMEA 0183 doet alles wat ik wil (en dat is best veel)
- ST60 Multi's doen alle nodige vertalingen van en naar Seatalk
- N2K heb ik niet nodig
- De mux heeft op Talker 1 alle data van 4 NMEA-sources voor alle apparaten die iets nodig hebben (VHF, Navtex, Radar, Seatalknetwerk)
- en op Talker 2 komen alleen data uit de PC: Performance (Tactictool), aansturing van de AP (uit Voyager).

De eerste reden die ik kan zien aankomen voor een nieuwe mux is de mogelijke aanschaf van een moderne plotter/radar. Maar zolang de oude Raymarine (2002, geen AIS) plotter/radar het doet is een nieuwe plotter niet nodig, al helemaal niet met de PC met Voyager.

Kortom:

omdat een update tot doel heeft de functionaliteit te verbeteren. En/of om aanwezige bugs te verwijderen.

Het is een beetje naief om te denken dat de update alleen is om functionaliteit toe te voegen. Uiteraard worden er altijd bugjes gevonden en verwijderd.
Als ze tenminste, zoals ik, naar de gebruikers luisteren. Kijk je nooit naar de bron code en doe je niks met feedback van de gebruikers, dan blijven de bugs er gewoon in zitten.

Bugs verhelpen is ALTIJD het geval, bij alles en iedereen, dus ook bij mij. Het blijft mensenwerk.

Basklusje, jij hebt dus een hele simpele opstelling. Qua multiplexer tenminste.

Overigens weet ik dat de miniplex ook software updates heeft in die tijd. als je niks te doen hebt moet je mn multiplexer draadje maar eens doorlezen. Vooral de discussies over true wind berekeningen leidde ineens bij de miniplex ook tot een software update.Met vermelding van de betreffende wijziging.

Prima hoor, het geeft maar aan dat we allemaal maar mensen zijn. Geen enkel apparaat als deze is foutvrij. Ook is de Roosmux behoorlijk uitgebreider in de functionaliteit, zoals de performance berekeningen en het Schrijven van data naar de seatalk bus met alle verschillende berichten.

Een programma met een hex file van 5 KByte heeft een stuk minder bugs dan die van 45 kByte. Ja, ik weet, uitzonderingen daargelaten. Jullie weten wat ik bedoel.

Er zijn overigens heel veel tevreden Roosmux gebruikers die zelfs nog nooit een update hebben gedaan. Net als BK met de miniplex.

Er zijn er ook een handjevol ,zoals Gary, die de mux tot in zijn voegen laat kraken.
Het is aan mij om dat op te lossen. En dat ga ik ook doen. Zelfs als het een hardware update betreft. (FPGA)

Tenslotte, ik draai wingps voyager.
Op kantoor gaf de pc versie netjes een update naar 2017 tijdens opstarten.
Aan boord dus niet. allebei win7. Dat viel me natuurlijk op.
Daar moest ik dus vanuit de website een update downloaden, toen ging ie wel.

Bug. ook bij de programmeurs van wingps dus.

we zijn allemaal maar mensen.

en dan noem ik nog niet eens alle bugs waar de windows programmeurs mee weg komen.
blauw scherm, oh even opnieuw opstarten!
Heb ik een bug dan valt het hele forum over me heen en ben ik ineens een hobbyist.

Maar geeft niet hoor, ben wel wat gewend onderhand . Ik blijf me gewoon focussen op dat waar ik goed in ben.

Natuurlijk zitten er altijd fouten in software. Dat is onvermijdelijk, omdat mensen niet logisch kunnen redeneren en computers dat nu juist altijd wel doen.

Maar met veel updates komen er ook extra risico's:
- nieuwe fouten in de nieuwe onderdelen
- nieuwe fouten in oude onderdelen wegens onverwachte interacties
- regressiefouten: oude (opgeloste) bugs die terugkomen door een niet-waterdicht versiemanagement.

Enige wijsheden uit de industrie:

The idea of bugs per lines of code isn’t really a new idea. Steve McConnell has written extensively on defects per lines of code. Covering average bugs per LOC stats in his great book Code Complete.

(a) Industry Average: "about 15 - 50 errors per 1000 lines of delivered code." He further says this is usually representative of code that has some level of structured programming behind it, but probably includes a mix of coding techniques.

(b) Microsoft Applications: "about 10 - 20 defects per 1000 lines of code during in-house testing, and 0.5 defect per KLOC (KLOC IS CALLED AS 1000 lines of code) in released product (Moore 1992)." He attributes this to a combination of code-reading techniques and independent testing (discussed further in another chapter of his book).

(c) "Harlan Mills pioneered 'cleanroom development', a technique that has been able to achieve rates as low as 3 defects per 1000 lines of code during in-house testing and 0.1 defect per 1000 lines of code in released product (Cobb and Mills 1990). A few projects - for example, the space-shuttle software - have achieved a level of 0 defects in 500,000 lines of code using a system of formal development methods, peer reviews, and statistical testing."

ja dat klopt. En dat zal ook niemand ontkennen.
Maar dan is het dus aan de programmeur zelf om in te schatten wat de eventuele nieuwe bugs kunnen zijn.

Voeg je twee zinnetjes toe dan is dat simpeler te overzien dan een grotere wijziging.

Afgelopen winter hoorde ik iemand hartgrondig schelden op een Simrad radar.
Die raar deed na een software update.
toch ook geen knullig bedrijfje zou je denken.

roozeboos schreef :
Als je functionaliteit gaat vergelijken vind ik het niet fair om de NMEA2000 en Seatalk functionaliteit van de MiniPlex 3 niet te noemen, inclusief de vertaling tussen NMEA2000 PGNs en NMEA1083 zinnen vice versa. Laat de gebruikers zelf oordelen welke functionaliteit ze belangrijk vinden.

En ook Meindert Sprang verwerkt gebruikerswensen in de MiniPlex 3 firmware.

Met je bugs betoog ben ik het overigens eens.

Was meer een reactie op Baasklusje zijn multiplexer van 2003. die geen updates nodig heeft.
Terwijl ik weet dat bijvoorbeeld daar de true wind aangepast is nadien.
BK heeft dus ook bugs in zijn mux, maar heeft daar geen last van. Dat is een heel ander punt.

Voor de duidelijkheid, alle respect voor meindert met zijn miniplex, hij heeft veel meer succes dan ik daarmee. En ook dat ie durft om te investeren in het ontwikkelen in een nmea2k multiplexer. Dat ga ik niet doen hoor.

roozeboos schreef :
dat heb ik vaker gehoord

En hoe snel is dat probleem opgelost? Daar ben ik wel benieuwd naar..

roozeboos schreef :
Vast niet zo snel als bij jouw Roosmux.

Ik heb van Meindert ook wel eens een hele snelle firmware uitbreiding ontvangen, maar jouw snelheid in firmware aanpassingen is volgens mij uniek. Leuk om te zien hoe je er bovenop zit zonder dat je er direct geld aan verdient.

roozeboos schreef :
Navico (B&G, Simrad, Lowrance) is een super knullige bedrijf wbt updates..heel slecht getest en bugs na update worden er pas laat opgelost. Vaak pas bij volgende update en er zijn heeel weinig releases...

RayMarine heeft het steeds beter door en ziet de hardware als een telefoon/tablet, regelmatige updates met nieuwe functies en bugs opgelost, maar bovenal een zeer goede changelog.

roberteb schreef :
"two wrongs make a right",

roozeboos schreef :
Alle sw heeft bugs, zelfs de sw die ik gemaakt heb de laatste 50 jaar.

Maar daar hoef je geen last van te hebben als je de dingen een beetje conservatief gebruikt.
- alle ST <==> NMEA doet een ST60 Multi, met alle kennis van Raymarine zelf van het niet openbare Seatalk-protocol en de datagrammen.
- True Wind: laat ik door de ST60's (Wind en Log) berekenen. Gewoon deel van het Seatalk systeem
- Performance: uit Tactictool, waar ik de bronnen (MWV of VHW, en STW of SOG) zelf kan kiezen.
- een ST60 Multi zonder Seatalk-data (schakelaar in gele draad) om de performance (uit een VTG) te tonen
- een stuurautomaat (ST5000 sailpilot) die of door Seatalk of door NMEA wordt aangestuurd (schakelaar).

Zo hou je de boel een beetje losjes gekoppeld en vermijd je ongewenste interacties.
En heb je geen behoefte aan een ingewikkelde mux, al 16 jaar niet terwijl er toch een behoorlijk complex systeem aan boord is. Ik ken er niet veel die de electronica intensiever gebruiken (alleen 3Noreen, eigenlijk).

roozeboos schreef :
Een raw log van mij is al heel snel 20Mb. Ik zit hier op mobiel internet.
Verder gaf de laatste software alleen maar meer fouten dan de versie x2F die ik nu gebruik.

Wat bijvoorbeeld een wat verontrustende heel basale fout is waardoor mijn vertrouwen toch een deuk gekregen heeft is deze;

Mijn op de mux aangesloten airmar log/diepte gever stuurt het volgende bericht

Uit airmar
$VWVHW,,T,,M,0.00,N,0.00,K*54
De mux stuurt dan door
$VWVHW,,T,,M,0.0,N,0.00,K*54

Duidelijk te zien dat er een 0 weggehaald is. Waarom eigenlijk ? Maar de checksum is niet aangepast. Vervolgens accepteert mijn NKE instrument natuurlijk het bericht niet. In mijn idee ga je niet in de software aan zo'n bericht knutselen zonder dan daarna de checksum aan te passen. Maar in de eerste plaats waarom word er aan dit bericht geknutseld. Dat wil ik helemaal niet. Waar word nog meer aan gesleuteld zonder dat ik daar weet van heb.

Idem gebeurt er iets degelijks met andere zinnen.
Waarom ik geen diepte meer zag terwijl ik hier de Ore over de drempel binnenliep.

Uit mux
$SDDBT,,f,0.0,M,,F*28
Uit airmar
$SDDBT,,f,,M,,F*28

graag een log van 2 secondes , is dat ook zo groot?
Anders krijg ik het wel bij terugkomst.

Wat zit er nu precies aangesloten op die betreffende mux?

Baasklusje schreef :
You ain't seen nothing yet!

Andere data in een bericht met toch dezelfde checksum (een CRC32) kan alleen als de checksum niet uitgerekend maar gewoon gekopieerd wordt. Is wel makkelijk en snel, maar een groot risico.....
De NMEA afspraak:

== NMEA Encoding Conventions ==

A NMEA sentence consists of a start delimiter, followed by a comma-separated sequence of fields, followed by the character '*' (ASCII 42), followed by a CRC32 checksum expressed as two hexadecimal digits, followed by an end-of-line marker.

CRC32: en.wikipedia.org/wiki/Cyclic_redundancy_check

37south schreef :
Leuk ! Ik heb een high speed anticiperend op komende golven, stuurautomaat. Heb jij ook zo iets in ontwikkeling dan zouden we ervaringen kunnen uitwisselen. Er zijn hier maar weinigen die de wiskundige achtergrond hebben om zulke dingen te doen. Het is altijd leuk om gelijkgestemden tegen te komen.