Onderwerp: Incorrect RMC bericht! Hoe kan dit?

roozeboos schreef :
De crux is de UP TO.

Dat zal slechts met zeer simpele instructies gehaald worden, en zeker niet gemiddeld.
Bovendien is MIPS niet gedefinieerd, de I staat voor Instructions, maar er is niet gezegd wat voor soort instructions.

Het is marketingtaal, geen tech spec.

nou okay. Je hebt gelijk.
tijdens een sprong zal er af en toe een dubbele clckcycle nodig zijn.
Blijft het feit dat jou lijst echt onzin is bij deze processor opbouw. Die lijst is van een oude 8051 ofzo.
Kunnen we nu weer door?

roozeboos schreef :

Mooi! En de processorbelasting?

nee dat kan je niet zien. Dan zou ik bij moeten houden hoe vaak de controller in de main loop draait zonder iets te hoeven doen.
En dan heb je de interrupt routines ook nog die op de achtergrond even de controller overnemen.
Dat is lastig hoor.

roozeboos schreef :
Zijn de wetten van de natuurkunde veranderd, de laatste 40 jaar?

Baasklusje schreef : ja

ww1.microchip.com/downloads/en/DeviceDoc/doc7926.pdf

De Instruction Set van de processor:



Klassiek 1990, niets bijzonders.

Bij veel instructies 2 cycles nodig (valt me mee), maar alleen bij het adresseren van het interne geheugen in de processor.
Een Note op pag 29:
1. Cycle time for data memory accesses assume internal RAM access, and are not valid for accesses
through the NVM controller. A minimum of one extra cycle must be added when accessing memory
through the NVM controller (such as Flash and EEPROM), but depending on simultaneous
accesses by other masters or the NVM controller state, there may be more than one extra cycle.
2. One extra cycle must be added when accessing lower (64 bytes of) I/O space.

Dus een cycle of 4 a 5 per instructie zal het wel wezen. Ik pas mijn eerdere 10 aan naar 5

sjonge jonge, nou dan heb ik je toch om gekregen. Het was weer een hele bevalling.
Daarom wil ik deze discussies niet.
is ook helemaal niet relevant

Een mooie oplossing voor supersnelle verwerking zou het toevoegen van een xilinx Spartan FPGA kunnen zijn.



De fpga regelt dan alle uarts en het bufferen. Een snelle processor ernaast voor het verwerken van de buffers.
Zou stoer zijn.

roozeboos schreef :
Nou, om gekregen.... jij zegt 1 cycle, ik zei 10, en we eindigen nu op 5. Dat is 5 keer meer dan 1, en 2 keer minder dan 10.

En de discussie is wel relevant.
Elke computer (de mux) heeft een bovengrens aan wat er nog doorheen kan.
Die kan worden bepaald door de processor, de I/O of het geheugen. (eventueel de perifere configuratie: schijven).
Die 3 moeten netjes in balans zijn, anders staan er 2 te nietsen en is er 1 overbelast.
Om te weten wat de mux aan kan en wanneer er fouten gaan optreden doordat 1 van de componenten teveel werk moet doen moet je weten wanneer en waar het fout gaat.
Overigens is een foutsituatie inhoudelijk nogal onvoorspelbaar. Worden er inputs genegeerd? Wordt er geheugen overschreven? Worden er outputs afgekapt? Allemaal erg afhankelijk van de error-routines in de diverse componenten.
Je kan echt niet volhouden dat het niet relevant is, want je zal de klanten toch moeten kunnen vertellen wat het ding wel en niet kan. Teveel vertalingen, te hoge inputrates etc kunnen vreemde gevolgen hebben.

moeten we nu ook nog gaan discussieren over hoever je om gaat?
wordt wel heel vervelend zo.

3Noreen schreef :
Grappig twee bladzijden verder en deze in mijn idee belangrijke info wordt overheen gelezen.

nee ik zag het wel hoor.
Afhankelijk van de instellingen moet de RMC uitgeplozen worden. Dat kost procecessor tijd.
Mjin vraag was ook nog welke versie je draait op de mux. Of wanneer je voor hjet laatst ge-update hebt.

10 Hz RMC is nutteloos ( geld ook voor alle andere gps data sentences), er is geen gps die 10Hz calculations doet alleen maar nutteloze data belasting, met 0,0 meer waarde 1 Hz meer dan voldoende en uit iedere gangbare gps is ook niet meer te krijgen.
10Hz is alleen gangbaar voor heading en pitch and roll calculations.

De toepassingen waar 10Hz wel of niet zinvol is, daat gaat deze discussie niet over.

Als de mux gespecificeerd is als "geschikt voor 38k én seatalk", dan moet ie daar ook op gedimensioneerd zijn zoals BK zegt. Worst-case, bij volledige IO belasting (seatalk bus dus óók vol) en alle mogelijke conversies zal ie er (zelfs nog met marge) aan moeten voldoen. Tenzij je dit niet claimt of uitzonderingen maakt in de specificaties.

Maar we weten nog steeds niet óf dit wel een processor belasting issue is, of dat dit een "gewoon" bugje, ergens anders is.

Misschien rek je de specificaties wel erg op deze manier, als je uitgaat van wat gangbaar is de tegenhanger van de Roosmux, is mogelijk wat duidelijker in de specificaties, bij overload wordt er gedropt. De mux uitvoeren met een overload ledje is dat ook weer duidelijk.

ja dat is nog wel een idee.
Ik drop ook natuurlijk. Als de buffer vol is, dan is tie vol.

Zou je eventueel, voordat je probeert een evt te lange zin naar de buffer te schrijven, hierop kunnen testen? Past het niet dan deze zin ergens anders parkeren. Je krijgt dan een extra wachtrij, waarvan je op basis van prioriteiten kunt bepalen of je een zin daaruit (mocht er weer ruimte ontstaan) alsnog wegzet. Tijdrelatie is dan wel verknoeid, maar je zou een AIS zin dan vóór kunnen laten gaan op een (in sommige ogen) nutteloss 10Hz bericht, waarvan er toch zat langskomen.

Ipv een IO overload led heb je toch al een prachtige interface? Een multiplexer zit vaak weggebouwd bovendien. Kun je zo'n processorload indicatie niet toevoegen op het diagniose scherm? Laptop USB koppeling is bedoeld dacht ik toch voor configuratie & diagnose?

Nachtvlinder voor de GPS sentences is meer dan 1 Hz nutteloos, sterke nog de GPS satellieten zouden aan een update toe zijn om dit nuttig te maken, het heeft 0.0 zin.
Dat wil je niet horen, maar het is zo, smoothing is minimaal al een seconde tussen de GPS berekeningen, maar daar ging het dan in jouw ogen dan weer niet om.
Een gangbare gps is ook niet in staat om meer dan 1 Hz te genereren, dat is niet voor niets.

Henk, dat is een heel andere discussie die een tijdje terug al elders is gevoerd. Hier is het linkje :

NMEA2000 /N2K/SeaTalkng versus NMEA0183

Ik heb je daar alvast gequote en gereageerd Kunnen we hier op de dataload blijven focussen. Want je zult het toch met me eens zijn dat je 10Hz kompasdata of de stroom AIS scentences in een druk gebied niet ongestraft naar 1 Hz kunt terug brengen?

heading 10 Hz is geen probleem, er zitten nauwelijks karakters in een HDT ( of G of M )
bericht, dat veroorzaak nauwelijks load en is verse actuele data, dat is zinnig, neem eens een RMC bericht tel de karakters (veel) en de bron, die is nooit hoger dan 1 per seconde actueel, ga je die kunstnmatig sneller uitgeven dat geeft je 9 sentences die alleen zorgen voor extra load met nutteloze exact dezelfde info, die is 9 x gewoon een kloon van het eerste bericht, nutteloos dus.

Dan even terug naar de mux, waarop is het ontwerp gebaseerd:
GPS, wind, depth, speed @ 4800 baud, AIS @ 38400
heading hangt af van de bron 4800 of bij een wat beter bron 38400 High Speed data
Seatalk conversie

en dan de uitgangen
plotter ivm met alle data gaat dat niet passen binnen 4800 dus moet die omhoog in baudrate
en wat repeaters en bv een VHF DSC, dan moet je al weer gaan filteren om dat deze listeners niet meer aan kunnen dan 4800 baud.

En daar voldoet hij inmiddels aan op nog een enkele seatalk omzet haperingn na.


Wil je op hoge frequentie alles loggen pak je een laptop en een bos com poorten en log je alles zonder tussenkomst direct naar een file, heb je geen enkele vertraging door bewerkingen in een multiplexer, gebruik dan een com server.

Hoeveel bandbreedte gebruikt een flink ontvangende AIS receiver van de beschikbare 38k? Blijft er voldoende over om een (al of niet volle, er kan vanalles aanhangen!) Seatalk bus én een aantal 4800 kanalen daarbij te multiplexen?

Volgens mij kún je helemaal geen specs claimen, het systeem zou overgespecificeerd zijn, tenzij je de output op 115k instelt, maar dat is weer niet zo standaard voor de gebruikelijke plotter.

Eigenlijk zou je (net zoals CAN dat doet) wat logica in moeten bouwen om overload te voorkomen. N2K doet dat op laag, controllerniveau, maar in een multiplexer kun je wellicht voor elk binnenkomend signaal/bron aangeven hoe belangrijk dat is. Loopt de uitgaande bus vol, dan worden de minst belangrijke berichten niet mee-gemultiplexed. Je processor mag dan nóóit de bottleneck vormen.

Maar is het probleem van TS nu al opgelost? Was het een issue betreft IO-load, processorload of een bug?

henkvd schreef :
Heb wat voorbeelden gegeven in het andere draadje.

TS ging dit weekeinde nieuwe logjes maken. Rechtstreeks uit de mux en paralel daar aan nog met zijn IPhone. En prioriteiten instellen om te zien wat dat zou opleveren.
Nog geen terugkoppeling gezien. Als hij slim is, is tie lekker aan het zeilen. Mooi weer voor ook. Dat logje zal wel komen

roozeboos schreef :
Na onze mail wisseling van 17 juni vorig jaar waarin wij gezamenlijk tot de slotsom kwamen dat het los van de mux de gps aan de Rpi aan te sluiten ben ik dat gaan doen. Verder dus ook niet meer bezig gehouden met updates om het via de mux op te lossen.
De reden dat ik het hier naar voren bracht was meer in het kader dat de processor van de mux bij volle belasting mogelijk aan zijn grenzen komt.

Natuurlijk zou ik geïnteresseerd zijn in een update naar een software versie die maen en lean alleen de data met filter mogelijkheid, drop on input, round robbin doorgeeft. Dus zonder alle verdere liflafjes. Eventueel een uit te zetten wifi. + tienduizend regels code voor zo'n muxje is misschien wat teveel gevraagd.

Ja, daar was ik al bang voor. Er is na die tijd nog heel wat verbeterd hoor.
Het zou zo maar kunnen dat het nu wel goed gaat.
Maargoed als het nu werkt met die raspberry kan je het ook zo laten natuurlijk.