Répétiteur/Afficheur universel

J'en voudrais bien un! :reflechi:

Bonsoir
J’ai postée une question concernant ce répétiteur
Peut’il fonctionner en recevant les infos d’un réseau seatalk transmises en wifi par un AIS watch XB800 ?
Ou bien sert’il uniquequement de répétiteur pour l’appli SailRacer.net d’un iPad ou i0hone ?
Merci

Bonjour, ce fil n'est qu'un cahier des charges .
Concernant Sailracer, il est lié à une appli si j'ai bien compris, et non directement au bus.

J'hallucine ?
Pas moyen de trouver un afficheur transflectif avec des caractères de ~ 20 / 25 mm !
Où merde-je ?

7 segments ? de ce genre là ?
fr.rs-online.com[...]hromes/

Non merci boatallo, la recherche porte sur de l'afficheur alphanumérique.
Objectif, afficher un cap, une vitesse, ...
Ce serait pas mal si, en plus, s'affichait quelque chose qui indiquerait la grandeur affichée, comme "SOG", "WCV", ou "RMB12"...

Merci Yannbis.
Je pensais trouvé des afficheurs ALPHAnumériques (matrice de pixel) un peu comme anderson69s.com[...]rry-pi/ ou en i2c comme www.atrylec.com[...]hp.html
mais de + grande taille.
Pas encore reçu mon piZero, mais je crois que je vais le faire avec un petit afficheur (je dois avoir ça qui traine), pour faire un POC. Et si je ne trouve toujours pas, je passerais à un petit e-ink. Je pressens que la différence de prix soit faible.

Comme ce sera pour afficher du texte en utilisation extérieure, je reste fixé sur du transfléctif, ou du e-ink, comme www.sainsmart.com[...]ry-pi-3
Mais, GRRRR, pas de LCD alphanumérique de grande taille en vente au détail ?

Attention au choix de l ecran e-ink.
De nombreux ecrans sont prevus pour afficher une image et rester figes, type etiquettes de supermarche.

Pour le repetiteur il est necessaire d avoir un affichage le plus dynamique possible afin de suivre le changement des donnees de navigation.

Il faut donc un ecran rapide et permettant de rafraichir seulement une partie de l'ecran, si non l'ecran ne suivra pas les changements de valeurs des donnees de navigation.
C' est pour cette raison que j' ai choisi pour mon projet le 6 pouces de waveshare, a la fois rapide et pouvant etre partiellement rafraichis.

Pas d'un iota. 8 jours au bateau, retour à la maison, un peu de repos, et j'y repars.
Le besoin n'est pas premier. La priorité est faible.

merci pour ce lien, je 'ai pas regardé les détails, mais un Kindle, hormis que ce soit un système propriétaire, est étanche et très lisible au soleil !
Intéressant!

Pas levé le petit doigt, même pas eu le temps de voir pourquoi mon RPi ne démarre plus depuis que vidant le bateau, le RPi sur le pont, une averse soudaine... et il ne démarre plus.

Non, j'ai fait le choix du bateau ;-)
Du coup ça retarde, un peu... , le reste. mais j'ai aussi un vrai besoin.
je vais me re-pencher de plus près sur le les MUX pour commencer!

Je n'avais pas encore pu ce projet des très actifs allemands de open-boat-projects.org

Cet afficheur/répeteur open source répond à peu près tout ce qu'on a listé ici et ailleurs et même plus (E-Ink, notamment)
Je n'ai pas encore lu en détail, c'est un projet en cours.

open-boat-projects.org[...]obp-60/
open-boat-projects.org/en/diy-multifunktionsdisplay-obp-60/

Standard size for a multifunctional display (110 x 110 mm)
Suitable for daylight
Waterproof
6 keys
Support of the following bus systems: NMEA0183/NMEA2000/SeaTalk/I2C/1Wire
Low power consumption
WiFi-capable
Bluetooth-capable
Expandability via I2C bus and 1Wire
Hardware extensions via I / O port
Autarkic usable with battery pack for several days
Standard electronics for compatibility with other device series (NASA, Clipper, Navman, etc...)
Freely designable housing and therefore adaptable to other device series
Openness (OpenSource, OpenHardware)
Rebuildability with hobby means due to simple construction
Use of ready-made electronic modules
Adaptability to different needs
Software library for the Arduino IDE (similar to M5Stack)
Software updates via Micro-USB and WLAN

C'est déjà une superbe réalisation!

Les indicateurs n'ont probablement plus beaucoup d'avenir sur nos bateaux.

Que veux tu dire? les boutons n'ont plus d'avenir? ou indicateur vs écran multiusage?

Intéressant l'afficheur,
(reste encore cher je trouve, env 150€)
1000 Nits / 5 Inch / Waterproof IP65 / 12v

Bonjour,
Avec un projet très similaire, je découvre ce post avec grand intérêt et plus particulièrement la réflexion relative au choix de l'écran.

De ma compréhension et de ce que j'ai pu lire dans les forums techno, les e-ink qui présentent l'énorme avantage du low power avec un fort contraste sont à proscrire dans le cas d'exposition au soleil, vieillissement prématuré de l'afficheur voir même dysfonctionnement opérationnels.

Je n'ai aucune expérience en la matière et l'ensemble des applications que j'ai rencontré sont toutes des applications indoor, (je n'ai jamais essayé de lisseuse)

Le fabricant de e-ink recommande la non exposition au soleil et dans tous les cas l'usage d'une protection contre les UV pour une application en extérieur.

Avez vous un retour d'expérience sur le sujet ?

Autre sujet de réflexion, l'usage de bouton tactile style inséré dans un boitier étanche en façade du répéteur.

Ce modèle fonctionne très bien en environnement indoor même au travers de la paroi plastique du boitier, je n'ai jusqu'alors pas eu l'occasion de faire d'essais en environnement marins, embruns, bruine, pluie ......

Peut-être que l'un d'entre vous a déjà expérimenté ce genre de produit, ma seule expérience se limite aux tactiles de tables de cuisson qui sont plus que troublés au passage d'une éponge de nettoyage ou liquide répandu sur la surface.

Hello,
Pour info, j'ai un projet en prévision. Il s'agit également d'un afficheur mais ce coup-ci pour mettre dans la cabine, au plafond, consultable quand on dort, ou du moins quand on est couché.
L'idée est la suivante: Je dors au mouillage, et quelque chose me réveille (bruit, mouvement du bateau, vent...) et je veux en un clin d'oeil avoir quelques données de bases:
- heure
- vitesse vent TWS
- vitesse vent max TWS max
- orientation du vent GWA
- AWA
- distance de l'ancre, j'aurai besoin d'un coup de main pour le calcul en fonction des coordonnées GPS.
- % charge batterie SOC
- ...
Et si je suis en navigation j'ajoute:
- heure
- SOG
- DTW
- ETA
- Données moteur: RPM, t°...
Ceci à base d'Arduino Méga et un Shield TFT 3.5' Touch 320x480 que j'avais en rab et ça reviendra quand même moins cher que d'ajouter un i70 ou un Triton B&G.
L'idée du TFT sensitif ma plait bien, il suffit dans un demi-sommeil d'effleurer l'écran pour qu'il s'allume et de l'effleurer à nouveau pour afficher la page de données suivante. Etant donné la taille de l'écran on doit pouvoir afficher 6 données par pages.
Je n'ai pas encore commencé, je vous tiendrai au courant.
Le top serait de développer ça sur une smartwatch de type ESP32 avec connexion wifi sur le réseau du bord.

Re-Bonjour,
Comme évoqué précédemment, J'avance par étapes sur mon projet de répéteur.

Voici donc une première ébauche sur base de Mega2560 avec afficheur 2,9" e-link et 5 boutons en Touch Pad sur la façade le tout dans un boitier de récupération, 100% étanche.

Données GPS, Girouette / Anemo assurés avec calculs vectoriels de VMC, VMG, TWS, BTW, DTW, TWS, TWA .... au travers de plusieurs pages d'affichages sélectionnables.

Le temps de rafraichissement effectif de l'affichage même en mode partial Refresh demeure une très forte contrainte, les 0,3s annoncés par les fabricants se matérialisent en 750ms ce qui rend le code plus complexe ( Interuptibilité pour gestion flux NMEA etc .... ) si l'on souhaite un affichage de l'ordre de 1 Hz ou même naviguer dans des menus de manière confortable. (choix de WP .....)

La fiabilité dans le temps va aussi devoir être démontrée car avec 750 ms ne sont pas inclues des rafraichissement complets ni Hibernate pourtant recommandés par les fabricants de e-link pour éviter les images fantômes etc ...

Très sympa d'aspect, confort dans la navigation des menus et de l'affichage discutable, je reste perplexe sur la longévité de l'afficheur, mais si celle ci est assurée, alors cela demeure une très bonne solution, j'aimerai éviter devoir utiliser un TFT, énergivore et plus encombrant pour l’intégration dans ce boitier existant.

Pour le code source, il reste encore à faire, optimisation de la fluidité d'affichage et de menus du fait de la lenteur de l'affichage, rendre le code interruptible pour ne pas perdre les flux de donnée NMEA, optimisation de la RAM car les librairies gérant les e-paper sont gourmandes et suis à l'étroit pour ajouter le code d'un IMU.

Reste donc à faire pour être pleinement satisfait.

Concernant le choix de l'afficheur, j'ai opté pour le mais les temps de partial Refresh annoncés ne sont pas au rendez vous et je ne suis pas un cas isolé sur cette référence équivalente à Good Display, il a l'avantage d'être interfaçable en 5V.

Pour les boutons, utilisation de TTP223, Attention la sensibilité doit être ajustée par l’adjonction de capa cms, soudures délicates.

Le tout par Ali-express

Hello Yannbis,

Oui, c'est une idée louable.
Mais ça va être délicat d'arriver à satisfaire tout le monde.
Chacun va vouloir afficher telle ou telle donnée, avec une disposition différente, et des données différents du voisin.
Quand à ajouter un menu de paramétrage permettant de choisir les données à afficher, ç'est faisable mais ça va être plus complexe.
Pour le moment, j'ai commencé mon mini projet avec l'afficheur TFT 3,5' couleur.
Un bouton On/off
Un bouton permettant de switcher d'une page à l'autre des données. Chaque page comportant 6 données.
Pour l'instant j'affiche des données aléatoires factices et je switch entre les deux.
Ce n'est pas compliqué, le seul pb a été d'optimiser l'affichage qui est un peu lent et donne un affichage qui clignote un peu.

Restera à récupérer les vraies données NMEA2000 sur le réseau. Pour cela je vais pomper dans le de Timo Lappalainen. Toutes les données que je veux récupérer n'y sont pas, je vais étudier ça.
Amicalement.
FX

En décomposant les fonctions, je pense que ce n'est pas si compliqué (mais c'est une vue de mon canapé)
Tout le monde ne veut pas afficher les même fonctions, mais tout le monde veut avoir à dispo dans le code les même éléments (vent, vitesse etc...)

Pourquoi ne pas utiliser un rpi zéro multitâches.

Je rejoins cette réflexion à 200%, c'est un choix judicieux que de tirer partie d'un coeur ARM.

Davantage par soucis de préserver ma zone de confort, environnement AVR et Arduino que je connais beaucoup mieux que les Rpi, si les temps de rafraichissement effectifs du e-ink étaient de 300ms comme figurant dans les spec, le multitache ne se justifierait pas vraiment, un MEGA 2560 suffisant amplement.

Le Multitache, pour qui maitrise l’environnement de dev, simplifie assurement la réalisation d'un tel projet et ce sont des choix qui se font dès le début.

Je demeure intéressé par connaitre les temps de rafraichissement atteignables sur un TFT, au cas ou il me faudrait changer mon fusil d'épaule et pourquoi pas passer au Rpi zero.

J'ai débuté mi Aout et avais l'objectif de finir au plus vite, devoir changer d'affichage et de CPU serait un re-départ a zéro.

Quel environnement de dev utilises tu pour le Rpi ? en C ou exclusivement en PHP comme j'ai pu lire plus haut, langage que j'ignore totalement.
Cordialement

Je n ai pas de vidéo pour montrer les temps de rafraîchissement, mais je vous donnerai cela dès que possible à partir du 15/11

Mon Hardware étant finalisé, donc pour la science je demeure très intéressé par les temps de rafraichissement que tu obtiens avec ton Pi Zero, j'ai d'ailleurs commandé un Pi Zero par curiosité pour faire des essais.

Contrairement à ce que j'ai pu écrire, au temps de rafraichissement, durée fixe même pour un refresh partiel de l'EPD, s'ajoute le temps de transfert en SPI qui lui a un impact sur le temps total d'affichage et est donc proportionnel aux nombre de données updatées.

Je n'ai aucun doute sur le fait que le Pi Zero/ARM gagne la course face à un AVR, mais dans quelle magnitude ?

Merci Par avance, pour ton partage d'informations.
Cordialement

Hello,

@Barsailer
Je ferai un chrono ce soir pour te donner la durée d'affichage d'une page.
En attendant, voici quelques précisions sur l'affichage TFT.

• Oui, la gestion des 2 touches est gérée par interruptions. La réponse à l'appui d'une touche est donc immédiate que ce soit pour changer de page ou pour éteindre l'affichage.

• Pour accélérer L'affichage d'un écran, à chaque boucle je ne réaffiche que les datas elles-mêmes. le cadre, les étiquettes et les unités ne sont pas réaffichées à chaque itération. Ca a bien réduit l'effet de papillotement.

Le pb de rafraichissement ne vient pas de la vitesse de l'Arduino. Il y a 2 autres facteurs.
- C'est l'écran lui-même qui est lent. Les e-Ink sont plus lents que les TFT. Entre TFT il y a aussi beaucoup de modèles et de pilotes. Le à moins de 10€ que j'ai a un pilote ILI9486 n'est pas bien rapide.

- La bibliothèque choisie est aussi fondamentale. Il y en a de plus ou moins rapides. J'en ai essayé une qui avait une très belle police, mais très lente. Du coup je suis redescendu sur une bib avec une police plus "system" mais plus rapide .

la solution pour la rapidité serait surement de passer sur un écran de type , qui a sa propre puissance embarquée.
Mais ça a un cout supérieur et un encore un peu cher pour un POC.

Amicalement.
FX

Bien jolies toutes ces réalisations.
Bonjour à tous et merci infiniment pour toutes vos pertinentes contributions.

Avec 240ms pour la mise à jours des données utiles, le TFT permet assurement une intégration beaucoup plus aisée sur un CPU monotâche comparé au e-ink que j'ai selectionné pourtant dans les plus rapide, annoncé à 0,3s sur la spécification du constructeur Good Display tout comme Waveshare.

La réalité est tout autre avec un temps fixe de rafraichissement de 750ms auquel il convient d'ajouter 200ms réveil/hibernation pour éviter la formation d'images fantômes.

Oui assurement le choix de la bibliothèque est fondamentale, j'ai essayer les codes de demo des 2 constructeurs ci-dessus, et en dépit d'un excellent support notamment avec Good Display, le code le plus rapide qu'ils aient pu me fournir (video a l'appui) ne fait pas mieux que les 950ms que j'obtiens avec la lib GxEPD2 finalement retenue.

Sur un e-ink, le rafraichissement partiel est un temps fixe qui ne dépends pas du nombre de pixel rafraichi, avec des menus paramétrables allant de 4 a 6 données par page, toutes les données sont rafraichies simultanément sans impact sur le temps réel.

Assurément il existe des e-ink plus rapides que d'autres, encore faudrait'il pouvoir se fier aux spécifications, à moins d'en acheter plusieurs et faire du benchmark sur les controller et les panels, aucun des 2 constructeurs consultés n'ont pu m'expliquer le pourquoi de cette différence de temps de rafraichissement avec leur spec.

Les e-ink ne sont assurement pas fait pour des taux de rafraichissement rapides, je dois donc encore travailler pour en amoindrir la lenteur en rendant le code d'affichage interruptible pour partie et donc gérer les flux de données.

Si je devais changer d'avis au profit d'un Rpi zero, avec plaisir je jeterai un oeil sur ton code gudhull, mais je préfererai garder le bénefice de ce que j'ai déja développé.

Au plaisir de vous lire.

Re-Bonjour,
Merci a fxvt et gudhull de m'avoir ouvert les yeux, Les E-ink/EPD sont desespérement trop lents et peu adaptés au rafraichissement de données multiples rapide.

J'ai choisis une plateforme Arduino CPU Monotache avec un EPD, c'est une erreur ne permettant pas de gérer des flux de NMEA sans pertes de données, l'interruptibilité du code d'affichage est beaucoup trop compliquée pour fonctionner de manière fiable.

Mon cahier des charge étant en priorité un repeteur tactic simple très faible conso d'energie pour navigation locales sans cartographie (cartographie optionelle via Tablette ou PC) j'evite de faire le saut vers le Muxberry qui parait très alléchant.

je maintiens donc l'utilisation d'un EPD selon le synoptique suivant:

A l'image du NEXTION (merci a fxvt pour l'idée), L'ajout d'un second CPU piloté par trames NMEA sur protocole propriétaire pour le processing dédié à l'affichage apporte pleine satisfaction. (certe l'affichage reste un peu lent)

A l'exception de l'IMU, toutes les fonctions ci dessus ont été implémentées et validés fonctionnellement sur flux de données réels sans pertes de trames.

Suis désormais impatient de tester toute ceci in situ avec du soleil, mais aussi de la bruine, des embruns .... et valider la pertinence du choix de l'EPD et des touch pad, Mais ce ne sera pas avant l'été 2022 je le crains.

Tout retour d’expérience d'EPD en milieu marin, hostile demeure bienvenu ;-)

Yannbis,

Pour ce qui d'un multiplexer NMEA0183, rien de plus simple, regarde la lib Arduino NMEAParser et les exemples associés.

Avec un arduino MEGA2560 et un poil de tripailles d’adaptation de niveaux HW, tu disposes d'un multiplexer 4 --> 1 en pas beaucoup plus que 20 lignes de codes.

Cordialement.

FX,
Le prix pique un peu les yeux, mais le concept est très intéressant, je vais creuser un peu le sujet.

Sur ton proto a base de TFT, as tu fait des essais de lisibilité par fort ensoleillement ?
Bien Cordialement

Bonjour, je suis à coté de la question, mais j'ai compris que vous étiez des doué en électronique aussi j'ai une question : je dispose d'instruments SIMRAD IS 15 et mon capteur vitesse/température me donne une info erronée pour la température aussi je souhaite changer ce capteur mais ne trouve pour le remplacer que le ST850 AIMAR mais je n'arrive pas à avoir une réponse des distributeurs sur la compatibilité de ce capteur avec mon IS15.
Par ailleurs, je cherche un écran combi IS15, car le mien les "digits" sont de plus en plus faibles.
Merci à ceux ou celui qui peut m'aider dans la recherche de solution à ces deux questions.
ci-joint l'image de mon combiné.
Michel

Merci barsailer pour toutes ces précisions très documentées, en effet le capteur Airmar 850 est compatible avec le ST 650 Aimar, donc j'imagine que si ce dernier est compatible IS15, le 850 l'est aussi.........
Quant aux données température, elles sont totalement erronées et donnent 60,,,68,,, pour une température de l'eau de 20 ou 22 degrés.
Vos réponses me sont très utiles pour rechercher une solution a mon problème.
Bonne navigation a vous.
Cordialement

Bonjour
68°F donne 20°C, une piste potentielle?
Philippe

J'avais déjà poste ce projet, mais perdu dans les limbes, les allemands avancent bien un afficheur/repeteur (et plus) avec ecran e-ink, NMEAs Wifi etc... en Open source HW+SW!
open-boat-projects.org[...]obp-60/