Onderwerp: Incorrect RMC bericht! Hoe kan dit?

Nachtvlinder schreef :
Nogmaals een framboos kan er keurig met datastroom van 38400 baud van maken. Verder als de mux in de fout gaat komen er willekeurig afgekapte zinnen uit. Naast natuurlijk het merendeel goede zinnen. Maar je wil niet dat die afgekapte zin een ais bericht is van een schip wat net van koers is veranderd en van plan is jou zou overhoop te varen.

3Noreen schreef :
Helder, 10hz stelt je voor andere uitdagingen, maar dat schreef je ook al

Wat betreft Seatalk op de Roosmux. Dat is niet zo maar goed gegaan nee, maar de laatste sw versies hebben een boel opgelost. Het gaat steeds dieper en dat brengt nieuwe uitdagingen. Atm ervaar ik geen problemen, met mijn best uitgebreide Seatalk netwerk. Dat is hoopvol voor TS

Nou nou wat n drukte.
10 Hz is nogal wat. Ik zie hier een RMC bericht van ongeveer 60 bytes. keer tien in 600 bytes.
op 38400 duurt alleen het verzenden van de bytes al 0.125 seconde.

Het zou kunnen helpen de baudrate te verhogen naar 56k2 of zelfs 115200.
En je moet de multiplexer ook slim instellen. Geen dingen doen die niet nodig zijn.

welke software versie draai je in de multiplexers 3Noreen?

Maar 3Noreen beweert dat er geen probleem is met de baudrate...

Als, zoals je zegt, het verzenden dan één datapunt al niet binnen 100 ms lukt, dan past dat inderdaad niet (ook niet op een RPi lijkt mij).

Ter informatie: volgt de processor in de mux de baudrate, qua executie interval etc of draait dat deel onafhankelijk daarvaan op (veel) hogere snelheid?

Aangezien de software versie zo kritisch blijkt: wat voor wijzigingen zijn er in de laatste versies geweest? Kleine, onbelangrijke bugjes of meer fundamentele dingen die hiermee te maken hebben?

als de baudrate verhoogd wordt heeft de mux meer tijd over voor het processen van de data.

De data wordt op interrupt basis ingelezen, maar de mux kan pas processen als het bericht kompleet ontvangen is.


vwb de software versie, er zijn in de loop van de jaren behoorlijke verbeteringen uitgevoerd.
dus als je een wat oudere versie draait kan een update zeker helpen.

cpu clock = 30 MHz
Met een hogere baudrate is er meer tijd tussen de berichten.

Duidelijk, dank je.

Dus de baudrate móet eigenlijk omhoog voor 3Noreen's datastroom lijkt me. Dan zal een RPi er ook problemen mee hebben gehad lijkt mij.

Begrijp ik goed dat de processor meer dan snel genoeg is om deze 10Hz data te processen, maar dat ie z'n data niet op tijd weg kan sturen/ontvangen? Dus de buffers lopen vol? Wat gebeurt er eigenlijk, bij een volle buffer?

Ik heb per ongeluk ooit wel eens een loop gecreëerd waadoor de (hier CAN maar dat is ook gewoon serieel, vanuit de applicatie gezien) schrijfbuffer vol liep. Ik krijg dan een exception. Werkt dat "embedded" ook zo of is dat niet te vergelijken?

een rpi draait op een veel hogere cpu clocksnelheid. Daarmee kan hij dus meer doen in de tijd tussen de berichten.
die rpi zal wel linux draaien, dus hij moet ook meer doen.

Het voordeel van de mux is dat er geen operating system op draait. Iedere instructie die wordt uitgevoerd is dus voor de functies van de multiplexer zelf.
Ook het afhandelen van de buffers dus. Ik kies zelf wat ik er mee doe als een buffer vol raakt.

roozeboos schreef :
Bij de gemiddelde processor zijn er zo'n 10 clock cycles nodig om 1 instructie uit te voeren. Let wel, dat is 1 machinetaal-instructie. Om een stukje 'data' te verwerken zijn er al gauw 5000-10.000 instructies nodig. Voor een heel NMEA-bericht van redelijke lengte ben je zo 100.000 tot 200.000 instructies verder.
En dat processortje doet dus 3.000.0000 instructies per seconde, maakt dus zo'n 20 NMEA-berichten per seconde, als er niets fout gaat met buffers en wachten op input. De werkelijkheid zal eerder rond de 10 berichten per seconde liggen. Dan gaat de processor achterlopen op het aanbod.

Duidelijk.

roozeboos schreef :
Denk je dat dat het probleem hier is (aangezien je de uitgestuurde data niet kwijt kunt in 38k). Wat doet de mux als de buffer vol raakt?

Ik weet niet wat de keuzes zijn: gehele bericht overslaan, verminkt versturen? Check je van te voren hoeveel ruimte er in de buffer is voor je er een bericht in klaar zet? Als (als...) dit het issue is dan kun je wellicht een strategie bedenken wat het minste ongemak geeft. Als het niet past, qua processor en/of wegschrijven zullen er hoe dan ook keuzes gemaakt moeten worden.

@BK: dus je denkt dat het meer waarschijnlijk de processor is? Wat ik dan niet snap, is dat de GPS deze berichten wel (over 38k) de deur uit krijgt met 10HZ. Volgens Chris past dat niet binnen deze bandbreedte.

Nachtvlinder schreef :
Een GPS zal vast een aparte processor hebben om de data op de output te zetten (een UART), want de GPS chip is heel specifiek voor de GPS-signalen, en een 'gewone' processor zal er niet in zitten.

Jawel, maar als je elke 100 ms een bericht wilt versturen waarvan dat versturern 120 ms kost, dan lukt dat toch niet, op geen enkele manier? Of zou de GPS vanzelf terugschakelen naar een interval wat nog net wél lukt (bv 8 Hz)?

dat ligt aan je processor opbouw BK.
De atmel die ik gebruik doet 1 instuctie per clockpuls

Nachtvlinder schreef : ik zei dat tien berichten RMC 0.125 sec kost, niet eentje

roozeboos schreef :
Daar geloof ik vooralsnog even niets van.
1 instructie is veel te ingewikkeld om op 1 clockpuls te verwerken. Er zitten allerlei schuif-, vergelijk-, etc acties aan een instructie, elk op een volgende puls.

dat kan je dan niet geloven, maar toch is het zo. Jou lijstje is zoo 1970...
De atmel heeftHarvard architecture met pre fetching.
Terwijl de ene instructie wordt uitgevoerd wordt de volgende alvast gehaald.

roozeboos schreef :
Bewijs?

Je bent in de war met parallele instructieprocessing en prefetching etc.

BK, ik ga hierover niet in discussie met je. Het leven is te kort daarvoor.

Low power, high performance 8/16-bit AVR microcontroller featuring 128KB self-programming flash program memory, 8KB boot code section, 8KB SRAM, 2048-Byte EEPROM, external bus interface, 4-channel DMA controller, 8-channel event system, and up to 32 MIPS throughput at 32MHz. The AVR XMEGA A1U series features 100-pin packages.

roozeboos schreef :
Dat kan je wel zeggen, maar de mux raakt de kluts kwijt met 10Hz aanbod, zo bewijst deze draad.

Baasklusje schreef :
niet in discussie over het feit dat je instructie tabel niet klopt. Daar wilde je bewijs van.

Oeps, inderdaad 120 ms per 10 berichten. Desalniettemin gebruikt deze 10Hz data alléén al meer dan 10% van de beschikbare 38k bandbreedte. Hoe zit dat met AIS erbij? Volgens mij gebruikt 3Noreen ook eens 10Hz wind-data?

Vandaar mijn eerdere vraag: kun je de processorbelasting en bufferniveaus uitlezen tijdens bedrijf? Of verwacht je een bugje wat hier niets mee te maken heeft?

Baasklusje schreef : De roosmux heeft een AVR (RISC) processor met single cycle intructies.

roozeboos schreef :
Je doet me een beetje denken aan moderne computergebruikers, zoals mijn (volwassen) kinderen.
Die denken dat alles vanzelf gaat, maar in the end moeten er eenvoudige minimale elektrische operaties worden uitgevoerd: spanninkjes vergelijken en stroompjes doorlaten of blokkeren. Het blijven gedresseerde elektronen, tenslotte, geen wonderinstructies.

Nachtvlinder schreef :
no problem.
ja als je volgen aanvinkt dan kan je zien wat de buffers doen in real time:

Baasklusje schreef : het blijft bizar hoe je weigert toe te geven dat je er naast zit. Maar maakt niet uit hoor.
en weer door...