Onderwerp: Sailing Performance Dashboard op de Raspberry Pi

Baasklusje schreef : Ik denk dat je hier iets ophaalt om met de websocket te communiceren? Aangezien de SPD data wel in websocket komt, denk ik dat je 2 stukken code hebt die op verschillende manieren hetzelfde doen? Ik draai SPD in een lokaal netwerk op de pi, misschien werkt het ene stuk code daarvoor wel en het andere niet.

Baasklusje schreef :
Waarom zou de pi hier niet tegen kunnen. De pi vergeeft de gebruiker misschien wat minder fouten. Mogelijk wordt hier unicode en ascii vermengd.

michaelh schreef :
ThisPC_IP wordt (sinds recent) opgehaald om het IP te tonen van de PC waarop SPD draait, in een infoscherm bij de start. Dat maakt het makkelijker met eeen browser daarheen te gaan. De variabele wordt verder nergens voor gebruikt.
Werkt perfect op Windows.

Die Unicode is de Python versie voor deze smiley.
Komt keurig op het scherm, de webserver en de print in Windows.
Jouw foutmelding zegt dat hij niet 'in range 0-128' is. Kennelijk lust de Pi printfunctie hem niet.

Versie 3.7.1 is er.

- als ThisPC_IP niet kan worden opgehaald (op sommige Pi's dus) dan wordt dat 'not available'

- bij het printen van shiftmsg etc wordt het eerste character (de smiley) overgeslagen. Dan hoeft die Pi zich daar niet meer in te verslikken.

- webserverqueue 4 keer zo groot gemaakt.

Ik heb een enorme hekel aan dit soort uitzonderingen, die nodig lijken te zijn om fouten in een van de 100.000 versies van Unix/Linux te omzeilen.
In dit geval kunnen ze gelukkig, dank zij de universaliteit van Python, niet veel kwaad.
Maar het is het zoveelste bewijs dat al die Unix/Linux varianten narigheid opleveren omdat ze zich niet netjes aan de afspraken houden.

Even wat toelichting op deze 2 probleempjes:

- het IP adres (ThisPC_IP) wordt sinds versie 3.5.3 (eind april) opgehaald om te tonen in een opstartscherm. Zo kan je je browser makkelijker naar de html van SPD laten kijken (anders moet je dat IP opzoeken). Op Pi-fora zijn wat discussies over het niet (goed) werken van de standaard Python functie om het IP adres van de machine waarop het programma (hier SPD) draait. Het lijkt dus een bug bij de implementatie van die Python functie in (een van de) Pi-Os'en.

- op verzoek is zeer recent toegevoegd dat, als SPD headless draait (geen scherm, geen toetsenbord) en alle messages en info alleen naar de webserver gaat, dat dan die output (de messages) ook naar de standard Python printer gaat. Zeer eenvoudige wijziging (print(title,message)) toegevoegd aan de webserver-output-routine. Alles is dan goed te lezen (i.t.t. via de webserver).
En dan gaat het ineens fout, want in de messages voor windshifts en stroming kan een smiley voorkomen.
Keurig te zien op het scherm (Windows, linux), keurig te zien in de standaard output (windows, Linux), keurig te zien in de webserver, maar die smiley kan niet geprint worden door de Pi en dan stopt heel SPD met een foutmelding. Zo lullig kan het fout gaan....

(je moet zoiets moois als SPD natuurlijk ook niet op een speelgoedcomputer draaien)

Zo, best happy met de setup zo….

Een mooie, headless, boordcomputer.




En dat geeft dan buiten mooie cijfertjes:

Bij jou Jumpinjack werkt het altijd probleemloos, toch?
Wat is er anders aan jouw Pi vergeleken met die van michaelh?

Niet alle pi’s zijn hetzelfde en de software er op is ook niet hetzelfde.

Lees ook niet helemaal wat zijn probleem is/ wat hij voor elkaar wil krijgen.

Misschien is t dat ik gewoon maar een beperkt aantal veldjes doorgeef en happy ben als er 3 waardes op mn schermpje staan
Polar speed
Polar performance
Target TWA

Heb t hier met de actisense niet aan de praat gekregen, maar dat ligt aan de actisense. Verder draait t gewoon.
Het grootste ‘probleem’ zijn al die nieuwe versies met mooie toevoegingen.

En daarnaast zou ik de tips en tricks nog willen laten zien in de kuip. Dus nog eens kijken of ik de andere hanst plugin kan gebruiken voor een webpagina op de plotter. Maar dat is alleen ‘voor de leuk’.

Het werkt dus stabiel en toppie, voor de duidelijkheid.

Jumpinjack schreef :
Belangrijkste is denk ik dat de pi behoorlijk anders gebruikt wordt. De software die al op de pi draait zorgt voor een lokaal netwerk op de boot. Je kan het netwerk voor online services via een 4G dongle, wifi netwerk of je telefoon met internet verbinden, maar het werkt ook goed zonder. We hebben diverse aanpassingen gedaan om veilig remote support mogelijk te maken, maar ook om te voorkomen dat de browser bijvoorbeeld aangeeft dat SPD een 'onveilige' site is. Binnen het netwerk ga je met https://spd naar SailingPD, dus IP adressen onthouden hoeft niet.

Voor SPD lijkt het alsof SPD en SignalK op verschillende machines draaien doordat ze in verschillende docker containers draaien. We hebben een SailingPD waar je in een browser (of via RDP) de desktop kan zien en bijvoorbeeld opencpn kan draaien en een headless versie. Headless met een echte (reactive) web interface blijft qua bediening de voorkeur houden. Voor de headless SPD wilde ik de opstartmeldingen ook kunnen zien, ofwel via docker of via de SPD webpagina's of node red. In de vorige versies kreeg ik die meldingen nog door in node red, in de laatste niet meer. Het kan zijn dat dit aan de pi ligt, maar zonder meer logging of info over de software kan ik alleen maar signaleren wat ik aan de buitkant zie.

De setup zal dus zeker anders zijn en wat andere eisen aan de software stellen, maar dat lijkt me niet per sé slecht. Ik denk ook dat je software er uiteindelijk meer robuust van wordt.

AvNav draait ook op de pi, maar ook daar lopen we tegen software aan die allerlei aannames doet. Om die ook op onze manier te kunnen draaien moeten we er achter moeten komen waar precies de problemen liggen om daarover met de ontwikkelaar te kunnen overleggen.

Uiteindelijk zorgt dit ervoor dat we alle data en schermpjes op de boot op veel manieren kunnen tonen, koppelen met andere data en weer gebruiken in andere applicaties en ook makkelijk nieuwe applicaties kunnen koppelen.

Ja, da’s een andere setting.
Alles draait bij mij gewoon in openplotter op de rpi.

Had vroeger ook een dongle, maar nu een losse 5G puck voor t internet. Mn plotter zit op dat netwerk en levert info voor de ipad oid indien gewenst.

Bij mij is t: pi aan nadat t navigatie netwerk op is. En weer uit na t zeilen.

Wil ik er bij dan kan dat via de local rpi hotspot. Of ik hang de usb drive aan mn laptop.

Wat simpeler dus.

Ik zou t toch echt embedded oplossen. dus zonder rpi of rtos of wat dan ook....

wat is t nu helemaal, er komt wat data binnen, er wordt slim aan gerekend en er worden berichten met het resultaat verzonden.
Zeker in het headless geval.
Een slim boxje dat altijd werkt. En vast nog minder vermogen verbruikt ook.
Zie velen hier weer in dienst staan van het RTOS en zijn perikelen , zo zonde .

Roozeblij schreef :
Zoveel mensen, zoveel wensen voor verschillende oplossingen. Met een iets meer modulaire oplossing (berekeningen geïsoleerd) kan iedereen de door hem/ haar gewenste oplossing nastreven, gui, embedded, webserver, plugin en zonder al die os/taal afhankelijke zaken zijn de berekeningen ook makkelijker te porten.

Roozeblij schreef :
Ik denk dat het dat al wel is.
Bij mij en anderen met Windows 10. Geen omkijken naar.
Bij jumpinjack op een Pi. Spanning erop en het werkt.
Opstarten kan 'Noquestionsasked', doorgaan igv verbindingsuitval en herstel kan nu ook.

michaelh schreef :
Dat is vreemd....
Aan de webserver-output (input voor node red) is met v 3.5.1 van 8 april op verzoek wat gewijzigd, heb je dat gemist?

· All messages (info, error, question) in headless webserver mode are now Python dictionaries instead of plain text strings. This makes them easier to handle (JSON) by programs using the webserver output.

Kan dat de oorzaak zijn?

SPD verandert niet vanzelf
En alles wat ik verander meld ik keurig in de readme en het Versions document.
Geen verrassingen.

Sja dus niet he. Lezende al de problemen in dit draadje. Het leven is echt te kort om dit soort toestanden te moeyen debuggen.
Maar prima hoor. Vooral doorzetten !
Een custom design embedded oplossing is ook alleen maar te doen met minimaal 25 tot 50 gebruikers.
Zijn die er al?

Weet niet hoeveel gebruikers er zijn, de download is zonder aanmelding.

michaelh heeft een paar gekke problemen; geen IPadres kunnen oppikken met de standaard Python routine en geen smiley kunnen printen. Dat zit vast in het OS van zijn Pi, kan haast niet anders. Heel erg is dat allebei niet, en bovendien alweer opgelost (omzeild)....

De Node Red (code van michael) zal vast niet meer werken omdat die niet is aangepast op de veranderde message layout van de webserver begin april. Dat is extern voor SPD, ik heb geen idee hoe dat werkt.

Bovendien: ik heb het voor mezelf en voor Windows gemaakt.
Nou blijkt het dankzij Python ook op Linux(Debian) en op 2 soorten Pi-OS ook te draaien, zonder enige wijziging (100% dezelfde code).
Dat is mooie bijvangst, toch?

Baasklusje schreef :
Ik ben er weer . Ik had de delay van de messages op 0.01 gezet met als gevolg dat er geen output meer uit kwam. Ik dacht dat het getal ook kleiner dan 1 kon zijn....
Ik heb spd nu weer aan de boot hangen. Output in signalk, browser, kip etc.

michael,

de web msg delay kan zeker kleiner dan 1 zijn. Zo klein als je maar wil.
SPD doet daarmee een simpele Python sleep() ter lengte (in seconden) van die waarde.
Wellicht ook een Pi-OS dingetje

Vraagjes:
- werkt de print van de smiley (die met v 3.7.0 wordt overgeslagen) nu wel?
- wat voor IP staat er bij de start in de info-messages (voor de PC waarop SPD)? Of staat er 'not available' (komt er als de gethostbyname() mislukt zoals je eerder had)
- Heb je nog wat gewijzigd aan je Node Red code? Die gaat mee in de download en dan moeten we wel een goed werkende versie mee-leveren!

Fijn dat het weer werkt!

hanst schreef :

Heeft iemand hier nog verder mee geëxperimenteerd om de door SPD uitgestuurde laylines zichtbaar te krijgen in het B&G Sailsteer scherm?

Mooi project, en misschien wel het meest populaire techdraadje. En omdat een ander populair draadje gaat over energie besparen moest ik opeens denken aan een thesis over hoeveel energy een bepaalde programmeertaal verbruikt, zoals hier o.a. Phyton is gebruikt.
En dan valt er nog een hoop te winnen....zie hieronder de genormaliseerde waarden:


of in meer concrete getallen:



hele rapport hier te lezen

Denk dat je dat in een nieuw draadje moet voeren.

Ik denk dat t trouwens veel meer afhangt van de hardware. Zeg ik als embedded hardware en software ontwerper.
Veel te vaak wordt gekozen voor een energie slopend real time operating system. Zelfs als er maar een relaistje geschakeld moet worden. Tegenwoordig ligt bij het ontwerpen van chips de nadruk op ultra low power. Je hebt t dan over 1 of 2 micro ampere in slaap. Dan moet je dat natuurlijk wel gebruiken.

Nachtvlinder schreef :
SPD geeft de tijd tot de layline, de afstand, en uit de ook gegeven optimale UA of DA kun je de layline berekenen.
De kant=en=klare layline wordt niet door SPD uitgestuurd.

niet of nog niet?

SPD heeft soms van dat soort magische aanwas.

Jumpinjack schreef :
Ja leuk he

Als iemand me vertelt welke gegevens nodig zijn om een layline via N2K ergens te tonen dan zou dat zomaar in SPD kunnen komen.....

Roozeblij schreef :
Uit die tabellen blijkt (natuurlijk) dat gecompileerde talen veel sneller en goedkoper zijn dan geinterpreteerde. Volstrekt logisch natuurlijk. In feite voer je assemby language uit met een gecompileerde taal.

Hier nog weer eens een SPD Pi van scratch aan t bakken om 1 van de mannen hier ook de 21ste eeuw in te helpen .

Zag dat er in de node red installatie instructie nog een extra instructie bij moet:

- install the signalk-node-red package in Signal k
- install de extra unit converter functie for node red in the terminal:
cd ~/.signalk/red
npm install node-red-contrib-unit-converter
npm install node-red-dashboard

- use the signals webapp for node red
- import the json file as a new flow
- press ‘deploy’

- change the SPD wifi ini file to match the 8080 port on the red node json definition. (or adjust the node red flow)

Voor de Navico/B&G gebruikers hier: je kunt nu de naam van de User en Remote velden zelf zetten. Max 8 chars voor short name (standaard scherm) en 16 voor de long name.

Dan met de B&G performance plugin de values sturen.



Dus mocht er een waarde zijn waarin B&G nog niet had voorzien, dan is dat hiermee op te lossen.
Voor nu alleen geen eenheid, dat is nog niet gelukt om te zetten. Het aantal decimal (0-4, auto) is wel in te stellen.

Link naar de performance plugin
Link naar de rename plugin