Bon en fait, il fait de la merde. Ca se voit sur la vidéo suivante à 50 secondes  quand il teste couple vers la gauche avec le plugin Boomslangnz:
https://youtu.be/RZ9UDp_leFM?t=50&is=bf88gjkZ-e7uOonE

Pour ceux qui ne savent pas décrypter, le moteur est "energisé" sur une phase mais ne va pas en couple vers la gauche.
Donc en gros il balance toute la tension sur une phase ce qui fait aligner le rotor dessus, mais ne contrôle rien du tout et surtout pas le couple. La preuve, le moteur ne va même pas jusqu'à la butée.
Cest donc une carte completement inutile.

Intéressant, enfin une solution DIY pour les volants modèles B & C !

Il faudrait voir si le FFB n'est pas du type "tout-ou-rien" (à fond dans un sens ou dans l'autre), car par exemple sur la carte model 3, on ne voit pas d'entrée codeur alors la commutation des phases doit être super basique, genre commutation forcée sur deux phases au lieu de trois. Pour rappel, les moteurs des panels B & C sont des triphasés (synchrone à aimant permanent).

Pareil pour la puissance car il faut quand même envoyer des watts aux moteurs (500W pour panel B en prise directe et 200W pour panel C) et bien que les transistors semblent adaptés, pas sûr que le courant soit suffisant car l'alim est une Meanwell IRM-30-48, c'est à dire 30W à 48V...   Ca fait à peine 0,6Ampères !

Tiens, j'en profite pour vous montrer ma carte en cours de développement pour faire du FFB "pro" avec des moteurs brushless ou DC ;-)

Entrées potentiomètres, encodeurs, capteurs Halls. Alim 48V externe, courant max 20A (50A pic) et mesure de courant pour asservissement en courant/couple.
Devrait aussi être compatible avec panels B & C, ainsi que les moteurs DC (Happ, Namco, Konami, etc...)

Je vais aborder maintenant le cas du AD725 dont la datasheet est dispo ici.
Ce dernier est plus récent que le AD723, et semble plus simple d'intégration. Il reprends le même principe d'oscillateur 4FSC et de Luma Trap mais est basé sur des sorties analogiques avec un bias DC (offset) qu'il faut supprimer en utilisant un couplage AC en sortie, c'est à dire en ajoutant des condensateurs de large valeur pour supprimer l'offset et ne laisser passer que les hautes fréquences.
Voilà le schéma extrait de la datasheet, où j'ai volontairement supprimer la partie basse qui montre une seconde sortie pour un moniteur supplémentaire, inutile pour ma carte.


On pourra remarquer que le schéma est très proche du AD723, avec quelques pins en moins, notamment la correction d'offset qui disparait (CVSET, YSET, CSET), la suppression de la possibilité de faire une terminaison 75Ohm (RT,GT,BT) et d'autres petites options.

J'ai utilisé l'IA (Gemini) pour m'aider sur le choix de composants et pour essayer de faire au mieux l'intégration sur un PCB.
Beaucoup de gens utilisent maintenant l'IA tous les jours (pas vrai @Little_Rabbit ?) et je me suis dit que c'était l'occasion d'essayer aussi sur des sujets plus complexes que de rédiger un résumé d'un texte ou faire les devoirs à la maison.

On dit que l'IA est performante pour faire du code. Comme c'est mon métier, je peux juger et avouer que ce qu'elle fait est d'un niveau basique (souvent très buggés), mais effectivement ca fait gagner du temps. Là pour l'électronique, je me suis dis que j'aller essayer. Petit bilan à la fin ;-)

Le premier PCB que j'ai fait est pour le AD723 et se base sur le schéma issu de la datasheet.

Je n'ai fait que reprendre ce dernier et ajouter un oscillateur de Pierce à base d'un quartz à 20ppm et d'une porte inverseur 74HC04 pour générer les clocks 4FSC (4 fois la fréquence NTSC soir environ 14MHz, ou 17MHz en PAL) comme demandé dans la datasheet, et le circuit du Luma Trap.

Après réception, montage d'un banc de test avec une TV, une video amp, un convertisseur hdmi2vga, soudure des composants, et premiers essais : c'était (presque) la cata !

En mode NTSC, j'arrive à avoir une image en S-Video, mais en composite image en noir et blanc, problème de synchro, bref pas top. En PAL pas de couleur et pas de synchro. Armé d'un oscilloscope et d'un peu de volonté, j'ai essayé d'investiguer :
- j'ai un problème de raccordement ou de routage ?
- mes modelines ne sont pas bons ? (pourtant faites avec switchres)
- l'oscillateur n'est peut etre pas à la bonne fréquence ? (ou mon oscilloscope ne mesure pas correctement, va savoir !)
- ma TV a un problème ?
- mon schéma est pas bon ?
- ?

Du coup, je tatonne, je change les condensateurs de mon oscillateur (ca fait changer la fréquence mais je ne sais pas si c'est mon oscillo qui mesure mal ou mon circuit qui est pas bon), je controle les signaux VGA en entrée, le Luma/Chroma en sortie. Je demande de l'aide à Gemini qui m'indique de vérifier si le signal de sortie contient bien le burst sur le chroma qui sert à calibrer le noir sur les convertisseurs DC (ceci est fait à chaque ligne). Pratique mon oscillo a une fonction de décodage de trame NTSC ou PAL, alors je l'utilise et effectivement j'ai bien le burst et tout semble correct, mais toujours pas de couleur ! Mais je remarque qu'en mettant mes doigts un peu partout au niveau de la zone oscillateur, parfois j'arrive à accrocher la couleur quelque fraction de seconde. Il semble donc que le soucis vienne bien de l'oscillateur.

En creusant sur internet (cette fois sans l'IA), je me rends compte que l'oscillateur n'a probablement pas la bonne fréquence. La datasheet indique qu'il faut rajouter une trimmer cap pour régler finement l'horloge, ce que je n'ai pas fait ! Les signaux NTSC et PAL sont extrêmement sensibles à la fréquence, cela se joue à quelques 100Hz près, et c'est probablement mon problème. Notez que l'IA ne m'a pas alerté sur ce point, mais qu'après lui avoir demandé elle m'a dit avoir oublié ce point très important ;-)

Je refais un PCB en ajoutant cette trimmer cap, j'en profite pour corriger quelques points comme la partie régulation du 3.3V, j'attends les PCB, et je reteste et presque le même problème ! Cette fois, c'est plus stable, ca accroche mieux mais le réglagle avec la trimmer cap ne change que de quelques Hz la fréquence et la mesure à l'oscillo semble toujours assez éloignée de la valeur théorique. Comme indiqué plus haut, je ne sais pas si c'est mon oscillo qui ne mesure pas assez précisemment, ou si c'est mon oscillateur qui n'est pas bon.

Alors pour éliminer cette inconnue, je demande à l'IA comment je peux générer une fréquence parfaite pour faire mes tests. Elle/il m'indique que le module DIY Si5351 peut m'aider. Pour ceux comme moi qui ne connaissent pas, c'est un module pour Arduino en 3,3V qui permet de générer des clocks quasi parfaites (0ppm de déviation) entre 8kHz et 160MHz, sur la base d'un quartz 27MHz (qui lui peut dériver). Il faut obligatoirement un Arduino 3.3V pour l'utiliser car il se configure en bus I2C et la config est perdue après extinction, ce qui veut dire qu'il faut le reconfigurer à chaque allumage.

J'achète ce module, je le branche, je contrôle avec mon oscillo et bonne nouvelle : mon oscillo donne une mesure finalement plutôt correcte (au 4ème digit) et c'est donc bien mon oscillateur à quartz qui n'est pas correct. Je connecte alors ce module Si5351 à mon PCB pour remplacer l'oscillaeur et fais un petit programme pour balayer une zone de fréquence autour des 14MHz nécessaires au NTSC afin de voir si j'arrive à obtenir la couleur.
Et là, youpi, j'y arrive ;-)

Il semblerait que c'est du à la porte logique inverseuse (une 74HC2G04GV, pourtant bien de la série des 74HC04) qui ne convient probablement pas et fait un signal trop "péchu". A nouveau, l'IA ne m'a pas conseillé sur ce choix mais après l'avoir questionné, elle me conseille d'utiliser un inverseur du type 74HCU04, qui a un comportement linéaire et non brutale sur ses sorties.
Nouvelle itération à venir !

Petit bilan sur la conception assistée par IA pour l'électronique : alors déjà elle ne comprends rien aux schémas et se trompe dans pas mal de chose, notamment les pins et la connexion des condensateurs ou autre petits éléments. Elle arrive bien à comprendre les datasheets et fait remonter les points essentiels à vérifier. Elle peut aider au diagnostique (bien qu'elle fasse fausse route on l'a vu sur le burst couleur) mais elle tombe souvent sur les pièges que, je pense, un vrai électronicien ne ferait pas (comme pour mon cas sur la conception de l'oscillateur qui ne marche pas).

J'en profite pour ajouter quelques images du premier proto de la carte où l'on voit le port VGA d'entrée à gauche, la sortie S-Video et RCA composite à droite, les quartz et l'oscillateur en bas à côté de l'USB, le régulateur et l'alimentation USB à côté et enfin en haut le AD723 avec les composants nécessaires à son fonctionnement (voir schéma extrait de la datasheet):


Et voilà la nouvelle version en attente de réception où l'on voit :
- en jaune des jumpers ajoutés pour choisir si l'on envoie une synchro séparée ou combinée sur le H, le choix d'avoir une terminaison 75ohm sur l'entrée VGA, et le choix du mode de transcodage pour le PAL South America (qui sera probablement jamais changé).
- en rouge la zone Luma Trap (dont on verra son efficacité dans une prochaine photo/vidéo)
- en vert la zone oscillateur avec maintenant deux trimmer cap pour régler la fréquence d'horloge NTSC ou PAL.

Dans les datasheets du AD723 et AD725, le Luma Trap est très bien expliqué.
Il s'agit d'un chevauchement des fréquences entre la partie Luma, qui donne l'intensité lumineuse, et celle du Chroma, qui donne la couleur. Le mélange des deux signaux par modulation entraîne une confusion au niveau du décodeur côté TV qui ne peut pas distinguer si le changement de fréquence est du au signal d'intensité lumineuse, ou s'il s'agit d'une couleur. Ceci n'est présent que pour le composite (un seul signal) puisque par définition en S-Video, les deux signaux sont séparés et donc le problème ne se pose pas. De plus, ceci n'apparait que si le signal de Luma contient des hautes fréquences qui chevauchent le spectre du Chroma.

La solution proposée par un circuit Luma Trap consiste donc à rejeter les fréquences de Luma qui pourraient perturber le décodage du Chroma (après le mixage), avec la contrepartie d'avoir une image un peu plus floue puisque les hautes fréquences du luma seront filtrées. Le filtre doit être accordé sur la fréquence de la porteuse du signal Chroma, à savoir 3.58MHz pour le NTSC et 4.43MHz pour le PAL.

La communauté Mister a finalement solutionné ce problème grâce à un traitement numérique à la source, dans le FPGA, avant sortie des signaux analogiques. Ainsi, les adaptateurs Mister vers S-Video ou Composite ne font que router les signaux déjà pré-traités en numérique vers des pins du VGA (qui n'est plus du RGB sur VGA) et le tour est joué, plus besoin de circuit analogique complexe.

Si l'on souhaite utiliser un PC avec une sortie vidéo RGB sur VGA, malheureusement il faut obligatoirement passer par un IC de transcodage et faire la correction du Luma Trap via un circuit électronique. Quand on lit la datasheet du AD723 ou du AD725, on voit que ce filtrage est prévu et il y a la présence d'une pin "YTRAP" pour relier un circuit résonant LC à un résistance interne afin d'avoir un filtre réjecteur. Mais il semblerait que les transcodeurs actuels fassent l'impasse sur ce circuit, pour une raison que j'ignore. Ou peut être volontairement pour retrouver le plaisir des artefacts du NTSC afin d'avoir les sensations "Retrogaming".

J'ai indiqué à Rion que ce serait tellement plus simple que ces adaptateurs soit modifiés par leur concepteur en rajoutant les 3 composants manquants, car pourquoi prendre le risque de refaire quelque chose qui fonctionne déjà ? Rion m'a indiqué avoir plusieurs fois demandé et insisté auprès des concepteurs de ces petits transcodeurs adaptés au retrogaming pour rajouter ce petit circuit mais malheureusement sans succès jusqu'à présent.
Et moi, dans une générosité qui me perdra certainement, j'ai finalement accepté de lui faire un petit proto de PCB sur la base du circuit exemple de la datasheet du AD723 pour essayer de refaire ce qui existe déjà et qu'il puisse essayer pour voir si le fameux circuit Luma Trap sert à quelque chose au final.

Me voilà donc embarqué sur la réalisation d'un PCB (enfin non, deux ;-) pour convertir du RGBHV de VGA vers du S-video/composite !

En tout premier lieu, le sujet du VGA vers S-Video/Composite.
Ce type de signaux vidéo sont présents sur la quasi totalité des TVs et moniteurs grands publiques bas/moyen de gamme de l'époque (la petite prise ronde à 4 broches pour le S-Video, et la fameuse prise RCA jaune pour le composite). C'est en particulier vrai dans les pays "NTSC" qui n'ont pas eu la chance comme nous d'avoir du RGB sur péritel imposé au niveau légal, bien qu'ils aient eu en compensation des entrées component YUV sur les modèles haut de gamme, inversement plus rare chez nous.

Rion et la communauté autour de Batocera et GroovyArcade ont déjà établi une liste de convertisseurs du marché compatible VGA (venant d'un PC, pas d'un mister):
https://github.com/ZFEbHVUE/Batocera-CRT-Script/wiki/Recommended-Adapters,-Sync-Solutions-&-Transcoders#-composite--s-video-transcoders

C'est adaptateurs sont souvent à base de transcodeurs, et non de convertisseurs qui bufferisent l'image.
Les transcodeurs n'introduisent pas de lag car ils traitent l'image à la volée, ligne par ligne, au fur et à mesure que le signal video est reçu.
Il apparait que les meilleurs convertisseurs sont ceux à base de Analog Device AD723 et AD725. Ces IC assez récents car datant de la fin de l'époque des CRT, ont la propriété de supporter une plage un peu plus large pour le trasncodage des signaux analogiques qui pourraient être légèrement différents des modes NTSC et PAL strictes.
Ils sortent directement les signaux Luma et Chroma pour le S-Video, mis en forme selon le standard choisi et peuvent mixer les signaux pour générer un signal composite qui intègre les deux (porteuse plus haute fréquence pour le Chroma).

En particulier, le transcodeur d'Antonio Villena est réputé pour fournir la meilleure qualité de signal en S-Video (Luma/Chroma séparé). Toutefois Rion m'a indiqué qu'en mode composite NTSC il ne gère par le Luma Trap et que malheureusement la qualité est mauvaise pour ce type de sortie. Le problème est également vrai pour pas mal de transcodeurs actuels.

Ne sachant pas ce que c'est que le Luma Trap, j'ai jeté un oeil à la datasheet du AD723 (disponible ici) et il s'agit d'un filtrage type coupe bande (notch filter ou comb filter en anglais) qui permet d'éviter un chevauchement des fréquences entre le Luma et le Chroma avant le mixage.
Pour ceux qui ne voient pas l'effet de l'absence de Luma Trap sur le signal composite NTSC, il faut regarder du côté de la communauté Mister, en particulier Mike Simone, qui a fait quelques vidéos à ce sujet :

C'est en particulier vrai pour les images noir&blanc avec du texte fin où l'on voit apparaitre des franges de couleur sur les caratères. Ici par exemple le signal composite d'un émulateur apple IIc:

(voir la page expliquant les artefacts et le filtrage sur le luma trap)

Salut à tous,
Je crée ce sujet comme une sorte de blog sur des bidouilles que j'ai faites récemment autour des sujets suivants :
- convertir du RGB sur VGA vers du SVideo/Composite.
- convertir un signal digital DisplayPort vers de l'analogique RGB sur VGA.

Il existe évidemment déjà ce type de convertisseurs sur étagère, à bas prix, alors pourquoi s'embeter ?

La première raison, c'est la curiosité ... et parce qu'un des développeurs du script 15kHz CRT pour Batocera (Rion), grand fan du VideoAmp, de Linux et de cartes graphiques AMD, m'a demandé s'il était possible de faire convertisseur VGA vers SVideo et composite d'excellente qualité, en particulier qui gère le luma trap du composite correctement, principalement pour les personnes n'ayant pas de CRT équipés en RGB.
Comme mes journées (et mes soirées) ne sont pas assez pleines, je me suis pris au jeu de regarder le sujet. Et en regardant le sujet, j'en ai profité pour aussi regarder si l'on pouvait dupliquer un convertisseur DisplayPort vers VGA qui gère les "low dotclock" et le EDID passthrough, ceci afin de compléter l'offre actuelle du VideoAmp.

L'objectif de ce sujet est de restituer ce que j'ai compris, et de répondre à vos questions si je peux. Il faut noter que je ne suis pas électronicien ni électricien. J'apprends par essai et erreur, et n'ai pas bcp d'expérience sur le domaine.

On peut brancher trois moniteurs sur le meme pc, mais encore faut il avoir une carte graphique qui les a les sorties et voir si flycast sait mettre en plein ecran ses 3 fenetres de jeu sur 3 moniteurs separés.
Jamais essayé.

Condoléances, et beaucoup de courage à tous pour passer cette épreuve.

C'est une borne JVS ? As-tu le schéma électrique ?

Citation de: Corwin le Dimanche 22 Mars 2026, 21:06:25 PMJ'ai deux courbes qui se croisent et se décroisent en fonction du volant et rien vu d'autres sur Outrun 2Spdx. Faudra que je regarde ce que ça donne sur un jeu fonctionnel pour comprendre car là c'est un poil obscur.

J'ai peut être mal compris cette remarque : les courbes devraient se suivre, ou tout du moins être de même signe, et ne pas être l'inverse l'une de l'autre. Si elles vont en sens opposé, c'est bizarre, et c'est peut etre un problème de potentiometre inversé ?
Peux-tu nous faire une video et mettre par exemple sur youtube en mode privé ?

Citation de: Tibal le Vendredi 20 Mars 2026, 01:12:24 AM- Pas de ffb sur Outrun 2
Si tes tests en Diag Mode dans BFF sont concluants, tu ne devrais pas avoir zéro FFB. Probablement un souci de paramétrage de l'émulateur (qu'il ne faut pas mettre à jour car sur les dernières versions, le FFB est une feature payante). @njz3 aura peut-être des pistes car il me semble bien que le FFB sur Outrun 2 pose régulièrement des soucis.

Je ne crois pas que la driveboard soit défectueuse si le FFB fonctionne par ailleurs sur d'autres jeux. Le mode Diag permettra de vérifier cela.
Le FFB est assez compliqué à configurer sur OR2. De mémoire, les jeux Lindbergh necessitent de copier le plugin FFB dans un sous dossier de Teknoparrot, en plus du dossier du jeu (c'est indiqué quand on clique "help" dans le FFB plugin).
Comme indiqué par Tibal, il ne faut pas mettre à jour Teknoparrot car les nouvelles versions ne supportent plus l'ancien FFB plugin.

Citation de: Tibal le Vendredi 20 Mars 2026, 01:12:24 AM- Erreur driveboard (au boot du jeu) pour Daytona 2 Batlle on the edge lors du lancement en single
Je ne sais pas pourquoi seul BotE single pose problème. As-tu essayé en RAW avec l'EPROM adéquate ?
As-tu vérifié que le bon Controlset se sélectionne automatiquement pour ce jeu ?

Bizarre cette erreur. Je ne me rappelle pas l'avoir déjà eu. Je viens de lancer BotE en single sur master et slave et il tourne.
Est-ce que tu as changé qlq chose dans la config de l'émulateur ? Manquerait-il un fichier dans la rom ?

Citation de: Tibal le Vendredi 20 Mars 2026, 01:12:24 AM- Jeux manquants en multi sur mon disque Slave (Je ne sais pas pourquoi)
Probablement parce que njz3 désactive certains jeux dans les menus selon la résolution choisie. Tu peux les réactiver manuellement, ou choisir un listing associé à une résolution supérieure (mais certains jeux seront écrasés 4:3 vs 16:9, et d'autres ne s'afficheront pas bien ou ne se lanceront pas sur CRT). Tu peux également lancer les jeux à la main (hors menu donc) pour évaluer s'ils méritent selon toi de rejoindre le menu.

Oui c'est la bonne explication. Selon la résolution je désactive les jeux qui soit sont inutilisables, soit tellement bugués niveau affichage que je préfère les enlever du menu hyperspin. Ils sont toujours présents sur le disque.

Citation de: Tibal le Vendredi 20 Mars 2026, 01:12:24 AM- Jeux Model 2 qui semblent moins fluides sur ma cab Scud en 384p Vs cab F355 en 480p.
Quand tu mets ton VideoAmp en 24k, tu as plusieurs fréquences verticales dispo (57,5Hz, 59Hz, 60hz). Laquelle as-tu sélectionné ? Logiquement 60hz devrait être le plus fluide puisque l'émulateur est calé là dessus, bien que ce ne soit pas fidèle au jeu original. Tu parles bien du jeu qui saccade et pas des voitures qui glitchent sur le côté slave ? Si c'est le 2e cas, plutôt un souci d'émulation, lié à M2LAGFIX.

Bonne explication également. L'émulateur model 2 est assez bogué et il est obligatoire de le faire tourner à 60Hz.
De plus, en mode Link, il y a des glitch graphiques et de communication. Malheureusement l'émulateur est tel qu'il est.

Citation de: Tibal le Vendredi 20 Mars 2026, 01:12:24 AM- FFb bizarre sur Virtua Racing
Tu as ajouté du gain, ou du permanent spring pour voir ? J'avoue ne pas trop me souvenir du rendu du FFB émulé sur ce jeu, mais je crois me souvenir que squallrs avait réussi à avoir un rendu correct avec une configuration matérielle similaire à la tienne.
Mais le défaut Driveboard reste possible en effet, mais tu le sentirais sur les autres jeux j'imagine.

De mémoire, le FFB de Virtua Racing qui est émulé par le FFB plugin ne propose pas bcp d'effets.

Citation de: Tibal le Vendredi 20 Mars 2026, 01:12:24 AM- FFb inexistant sur les  Initial D
Le FFB original n'est pas fou sur ID : ya du Spring effect, et des vibrations sur les bandes rugueuses. Rien d'autre, pas d'impact ni rien. Et en emulation, les bandes rugueuses sont à peine perceptibles, voire pas.

Aucune idée car pas d'expérience avec ces jeux.

Citation de: Tibal le Vendredi 20 Mars 2026, 01:12:24 AM- FFb désagréable sur Sega Rally 2.
SR2 ce n'est, d'origine, que Spring et vibrations. Pas d'impacts.
En émulé je suis d'accord que c'est injouable à moins de tout baisser fortement. En RAW, ça doit vibrer de manière assez uniforme. Si tu as un doute sur le "use RAW for this game", passe carrément BFF en RAW le temps de tester.

Ca c'est bizarre car le FFB de SR2 est plutôt bien émulé par Supermodel. Sur ta driveboard, quelle Eprom utilises-tu ? Comment est configuré le "Target Hardware" dans le BFF?

Citation de: Tibal le Vendredi 20 Mars 2026, 01:12:24 AM- FFb surprenant sur Daytona 2.
Celui-ci, même en FFB émulé, tu devrais pouvoir avoir un réglage convenable, entre baisse du gain, et augmentation du Spring. Mais rien ne vaudra le RAW.

Idem que pour SR2, Supermodel restitue très fidèlement le FFB. Cela peut etre un soucis de configuration Eprom/Target Hardware.

Ok, I found the explanation.
You have locked a file (like editing it) or a subdirectory (like having a software opening a directory) inside Documents/BackForceFeeder.

When you are in the ControlSet Editor and performing changes, the BFF actually modifies the internal structure of the directories and files. You likely have another software blocking this edition.
Please check the important message here :


So the solution is to not open a file or subdirectory and not mess this directory.
I will add a try/catch in the BFF to silently ignore this error, but still you need to not block a file when doing edition in the control sets.

Can you send me your current Documents/BackForceFeeder directory so that I try to reproduce your bug ?
No idea for the raw input 3 and 5 being activated. Maybe @Aganyte has an idea ?

Hi,
You probably have to use the "alternative pin mapping for FFB converter".
Then, if the raw inputs are still ticked, it means the hardware reports such input being pressed. Please check with a multimeter whether those inputs are GND (pressed) or 5V (not pressed, pull-up to +5V).
Regarding the crash, you should be able to add a new control set just by clicking "Add new" in the control set window. It could be a bug in the software (you use an old version). Try with a more recent version on my github to see if it solves this issue.

Totally Fury m'avait envoyé les sides seulement, en PDF. Les voilà sur un drive:
PDF side
Je n'ai pas les autocollants du siège ni du panel.