Onderwerp: Raspberry Pi performance box

Zal morgen die stekker eens opmeten - had geen idee dat Amphenol zó'n uitgebreid portfolio had! Misschien is er een ingestanst merkje oid te ontdekken.

Verder een beetje naieve vraag misschien, maar weet niet of de aansluiting aan Wifi-1 en Zeus gelijk is (waardoor je de kabel om zou kunnen/mogen draaien). Lijkt me wel - is me bij installatie niets over opgevallen in ieder geval.

Kan iemand kort uitleggen hoe dat nu werkt met "crossed en straight" kabel? Wanneer gebruik je wat?

Is dit niet de kabel die je zoekt?

www.ensslin.com/simrad-adapter...lb-auf-rj45/a-14914/

Crossed (of Null Modem serial) werd gebruikt om direct van netwerkkaart naar netwerkkaart zonder router/switch te werken..nl.wikipedia.org/wiki/Cross-overkabel

Ja die zoek ik, maar dan voor minder dan 50% van de kosten van een door midden geknipte eur 40 kabel Liefst een los stekkerjte dus...

Duidelijk betreft crossed - hier dus gewoon rechtdoor!

zonder commentaar

ja alleen is de grote vraag nu welke paren worden er niet gebruikt met slechts 5 polen

Dat was al beantwoord, wel goed lezen he

Klik

De huidige Ethernet connecties (switches e.d.) maakt geen verschil meer tussen cross en straight verbindingen. Auto-MDIX heet dat.

Voor snelheden onder de, ik dacht, 100 Mbit worden alleen de aansluitingen 1,,2, 3, en 6 gebruikt. Zie plaatje voor de nummers. De kleuren staan hiervoor al vermeld.
Maar dat had Xipias eerde geloof ik ook al gemeld

Zie ook deze link (Wikipedia) met pinning van de RJ45 connector en andere plaatjes.

Leuk projectje trouwens!

WADnWIND schreef :
Sorry nachtvlinder, niks in huis...

Dank voor de moeite!

Vandaag aan boord.

De connecties werken en alle apparaten kunnen elkaar zien (ping test). Polarplot krijgt nu live data binnen via de Websocket verbinding en de remote control op de telefoon functioneert.

Daarna eens in de metingen gedoken: hoe snel is die Tier-2 nu eigenlijk en wat is de resolutie van de metingen? Een hoge resolutie geeft minder noodzaak om sterk te filteren, terwijl een hoge snelheid voornamelijk van belang zou zijn voor de "Pitch & Roll" correctie.

Die real-timeliness valt nogal tegen. Ben er nog niet helemaal achter wat daar de oorzaak van is, maar ik verdenk een aantal van mijn Micky Mouse boord instrumenten, aangezien de bv (semi-professionele) RC42 (kompas) wél supersnel is met erg hoge resolutie.

Ga later off-line verder opzoek naar de specificaties van mijn sensoren (en die van betere (duurdere) sensoren). Wellicht wordt daar iets over resolutie en update rate gezegd. Ik heb niet de mogelijkheden om rechtstreeks op de N2K bus te kijken. Niet om nu opeens alles te gaan vervangen, maar om zeker te weten hoe dit zit.

Hieronder grafisch weergegeven hoe de belangrijkste datastromen eruit zien wat bovenstaand betreft. NB:

• Elk grafiekje is telkens een periode van 10s, geregistreerd met 10 Hz (10 markertjes is dus 1 s);
• De tijdreeksen zijn ná elkaar opgenomen en hebben dus niets met elkaar te maken;
• De meeste reeksen zijn verschoven op de Y-as om beter te kunnen zoomen. Y-as heeft dus niet persé de gebruikelijke waarden; echter de schaal klopt wel;
• Boot ligt stil in de box; logwieltje heb ik zelf wat zetjes gegeven. De overige beweging die je zit is afkomstig van het bewegen van de boot en variaties in de gemeten wind.

Ik heb onderstaande connectiemethoden vergeleken:

• NMEA0183 vanuit de TCP server in de MFD;
• Subscribed op de Websocket server; deze pushed nieuwe data wanneer ie dat nodig vindt (criteria daarvoor zijn voor zover ik weet niet instelbaar)
• Unsubscribed, geforceerd binnen gehaald (via een 100 ms timer) van de Websocket server.

Hierboven de heading van het electronisch kompas. Resulotie is erg hoog: verschillen in heading van 0.01 graden worden geregistreerd! Opvallend is dat de Websocket uit zichzelf slechts pushed met plm 2 Hz, terwijl de data zélf veel sneller geupdate wordt. De onderste trend laat zien hoe dat eruit ziet met 10 Hz.


Hierboven de AWA. Resolutie voor de 3 curves is gelijk, echter NMEA0183 geeft de data slechts met 1Hz. Websocket pushed met 2 Hz, maar duidelijk is dat de data via de bus veel sneller binnenkomt. De middelste curve laat zien hoe mooi het signaal gesampeled wordt bij 10 Hz.


Hierboven de AWS. Resolutie is slechts 1 knoop. Ik heb alle filters (Zeus en Triton) uit gezet; de diagnostic tool op de Zeus (ruwe data) laat ook zien dat er slechts 1 knoop verschil vanuit de sensor wordt geregistreerd. Op zich voldoende, maar wel opvallend.
Bijna links in de rode curve kun je zien dat er wel snel geupdate wordt.


Resolutie log is 0.1 kn. Sensor update slechts met 1Hz, waardoor sneller sampelen dan dat geen zin heeft.


Hierboven de heel en trim, belangrijk om de eerste afgeleidden roll resp. pitch te berekenen. Resulutie is prima (0.1 graden) echter de update rate veel te laag. Sensor refresh rate is niet sneller dan 1 Hz. Volstrekt onbruikbaar dus, deze data.

In het kort:
Hoe snel is de Tier-2 --> dat hangt van de aangesloten instrumenten af!
.

Nachtvlinder schreef :
Van die middelste curve zou ik heel blij van kunnen worden. Hoe kom je daar aan ? Het lijkt rechtstreeks van de n2k te komen.

Alle xxx_N2Kpulled curven komen op dezelfde manier binnen (vanaf de N2K bus via de MFD naar de websocket server die daarop gehost is).
Zowel die (mooie inderdaad!) AWA data als AWS data (die laatste met slechts 1 knoop resolutie) komen van dezelfde sensor!

Tenzij de MFD bedenkt dat 1 knoop resolutie voldoende is; wat ik me niet kan voorstellen. Echt zeker weten lukt pas als je (via zo'n Actisense module) op de bus kunt kijken...

Nachtvlinder schreef : Ik wil daar graag aan toevoegen:
En op welke methode je aftapt...

Elke netwerk-overgang of software-laag brengt potentieel verlies aan samples en toegenomen vertraging met zich mee.

Dat verlies aan samples is erg goed te zien in het verschil tussen de push en pull methode naar de GoFree router. We weten op dit moment niet of er ook nog sprake is van verlies aan samples ten opzichte van de N2k data op de CAN-bus.

Ik wil nog een punt extra toelichten: vertraging (latency).

Als je de winddata gaat corrigeren op basis van scheepsbewingen moet er, IN DE TIJD, een sterke correlatie zijn tussen de metingen.
De metingen gebruikt in het algoritme moeten in de tijd zo dicht mogelijk bij elkaar liggen. En dat is, vanwege latency en sample rate, niet altijd de laatst ontvangen meting van een bepaalde grootheid.



In het algemeen lossen we dit op door zo dicht mogelijk bij de bron tijdstempels toe te voegen aan de data en het algoritme hierop te synchroniseren. In sommige gevallen voeg je tijdstempels toe op basis van een eerder vastgestelde vertraging in de onderliggend componenten.

Goed nadenken over hoe je omgaat met latency in netwerk + algoritme voorkomt teleurstellingen over de uitkomsten.

Soort gelijke uitleg over real time had ik ook al in een ander draadje geschreven. Misschien is het toch te overwegen om zo'n Actisense module aan te schaffen.
De bedenkingen die ik daar bij heb is dat je dan toch zit met een uitgang op serieel nivo. En dus een omzetting met het verlies van de timing. Terwijl de Can-bus (n2k) juist ontworpen is voor real time applicaties. Het zo jammer dat je niet of nauwelijks toegang daar toe krijgt.
Een soortgelijke situatie zit ik zelf ook. NKE heeft een eigen bus.... Waar de wind data AWA en AWS een update om de 40 ms heeft. Echter lukt het me niet om deze in mijn RPi te krijgen. Ik blijf steken bij 200ms. Natuurlijk zit ik te hopen dat er een slimmerik een can-bus chippie aan zijn RPi koppelt én wil vertellen hoe die het doet om n2k uit te lezen.

Zou de iKommunicate hier een oplossing voor kunnen zijn?

ikommunicate.com/

En blijft die tijdvertraging constant? (Is er jitter?)

boarderbas schreef :
mijn idee is een constante + harmonische vervorming. Omdat sample rate verschilt 1,4,5,10,20,25 Hz

666 schreef :
Ik zit meer in de richting van zo iets te denken.

direct op de RPi met een real time chippie

3Noreen schreef : Dat lijkt wel de weg naar een snelle oplossing. Wat me niet bevalt aan die module (naast de prijs...) is dat er door die module filtering plaats lijkt te vinden (althans, volgens de canboat website). Een CAN-interface waar het NMEA kartel geen invloed op heeft, lijkt me fijner. Een zoektocht naar een CAN-USB interface geeft prima resultaten, maar het prijsverschil is niet groot genoeg om zelf dan veel tijd in een aanpassing van canboat te willen stoppen.

De diverse CAN-gerelateerde hobbyprojecten met de Pi, lijken ook precies dat: hobbyprojecten.

Wat betreft ikommunicate, dat valt onder de categorie: Yet Another Layer. Ze doen zowel een netwerk-niveau conversie (CAN naar IP) als een applicatie-protocol niveau conversie (NMEA2K naar Signal-K). Een groot feest voor latency (en jitter inderdaad).

Ik zit er over na te denken om een Actisense NGT-1 USB maar te gaan bestellen. Is er iemand die een adres weet waar ze voor een acceptabele prijs te vinden zijn? Het laagste tot nu toe dat ik zag is 110 GBP. Hiero.

Interessant, nu komen we op het gebied van real-time signaal theorie. Lang geleden voor mij dus schieten mag!

Daarbij gebruikt Polarplot stukken synchrone code (heet dat zo? Ik doel op een vaste, getimede executie) gecombineerd met asynchrone, event-driven data-handling. Absoluut niet real-time dus! Windows is ook geen real-time systeem: het systeem-timertje wat ik gebruik om de hoofdlus en logging te timen geeft alléén een event als daar even tijd voor is. De intervals tussen de timestamps van de PC klok (wat een system-call is) liggen (bij 10 Hz) tussen 95 ms en 109 ms! Dat is al een jitter van 14%; RMS zal de jitter rond 10% liggen.

Wat Erwin beschrijft zie ik als methode om de timing toch synchroon te kunnen houden (door correcties op de data in het tijdsdomein te doen op basis van die time-stamps). Eigenlijk ben je de data aan het her-klokken.

Zou dit ook nodig zijn indien het systeem een aantal keren sneller is dan de kritische snelheid van die toepassing, ofwel kunnen we er hier zonder die correcties mee weg komen?

De vraag is denk ik of dit alles echt van belang is bij deze toepassing. Ockam en B&G units draaien (real-time?) op 4 Hz en doen aan motion-correctie bij die snelheid.

Stel dat er (op die 10 Hz) af en toe een sample gemist wordt of een heel sample te laat binnenkomt. Is dat dan een probleem, wetende dat een 4 Hz timing in de praktijk voldoende is? Ik denk zelf dat jitter (zelfs als de klokruis 50% van dT zou zijn) nog steeds geen echt probleem is.

Wat 3Noreen en Boarderbas noemen zou ook van belang kunnen zijn. Valt (bij deze implementatie) alleen op te lossen door te filteren. Een eerste orde filter met tau=1s geeft al een group delay van >0.5s dacht ik. Zo'n filter dient dan op alle metingen toegepast te worden, zodat de dataset synchroon blijft. De traagste (laagst-gesampelde) meting zal bepalend zijn.

Verder zou het nog zo kunnen zijn dat een of meer van de sensoren zélf aan filtering doen. Formeel dient aan elke AD conversie een pre-sampling filter vooraf te zijn gegaan om aliasing in het digitale domein te voorkomen. Stel dat een analoog signaal met 5 Hz gesampled gaat worden, dan is de maximale frequentie die je kunt registreren 2.5 Hz (Nyquist, Fs/2). Dit vergt dan een pre-sample filter wat alle harmonischen met hogere frequentie wegfiltert. Doe je dat met een (slap) eerste orde filter (geen goed idee in het algemeen, je ziet vaker brick-wall filters), dan heeft zo'n eerste order filter een tijdsconstante van 0.5 s. Dat geeft dus een vertraging aan deze meting, terwijl een sneller bemonsterd signaal deze vertraging niet heeft.

Hierbeneden nogmaals de AWA en HDG, bemonsterd en gelogd met 20 Hz. Nu zie je duidelijk hick-ups ontstaan. Ook zie je dat dit ook de frequentie van de HDG sensor is, aangezien je vaker gelijke opeenvolgende samples ziet.



Op de bus kijken lijkt me nuttig, echter aan de sensoren zelf valt weinig te tweaken. Ik vermoed dat het er in Polarplot (in déze opzet) gefilterd moet gaan worden (zeker met tau=0.5s) en de mast-motion niet gebruikt kan worden...

Erwin72 schreef :
eur 172 op Advitek zie ik, scheelt niet echt... Ik ga je posts nog eens nalezen.

Hoewel niet erg waterdicht, dit staat er in de manual van Nexus:

3Noreen schreef :
Is die NKE bus gebaseerd op CAN of proprietary? Zo'n sensor klinkt goed (snél in ieder geval; heeft ie ook een hogere resolutie dan 1 knoop?)

3Noreen schreef :
Is een RPi eigenlijk een real-time systeem? Of lijkt het meer op Windows met haar taken, threads en prioriteiten?

3Noreen schreef :
Helemaal mee eens. Daarbij (als Polarplot nog eens echt iets wordt) biedt het de mogelijkheid om het (via een standaard interface) breed inzetbaar te maken voor boten die geen Navico aan boord hebben -en dat zijn er meer dan die dat wél hebben

Nachtvlinder schreef :
proprietary resolutie 0,1

In mijn idee is een ultrasoon wind meter achteraf gezien mogelijk een betere optie. Gaan massa !
NKE stuurt wel heel goed op zijn eigen windmeter.

Nachtvlinder schreef :
Als je de grafische interface van de desktop weg laat kom je naar mijn idee heel dicht in de buurt van wat je wilt hebben voor onze toepassing. ± 10 ms ? Daarnaast programmeer ik in C wat natuurlijk ook uitmaakt. Verder moet je niet teveel zooi in de USB en ethernet aansluiting steken. Niet er een multi media ding van willen maken.

Voor audio, digitaal audio processing, wordt er wel wat geëxperimenteerd met een RTOS. Daar komt het natuurlijk een stuk nauwer.
Nachtvlinder schreef :
Gelukkig kan ik me permitteren het hele zeil gebeuren als hobby te zien.

Kan je niet zonder operating system? Embedded software zoals het bedoeld is?
momenteel werk ik aan een project met een At32uc3a3 32 bits microcontroller , die heeft zelfs een dsp instructie set.
www.atmel.com/Images/32072s.pdf
Dat ding kan retesnel afwerken wat je wil volgens mij.

De vraag is ook of het allemaal wel zo snel moet?
Als er een windvlaag komt duurt het echt heel lang voordat je boot zich daar op heeft ingesteld hoor.