BlueDragon joue avec Arduino / RaspBerry

Hello Hello,

J'avance, j'avance ce week-end je faisais un stage de TK avec Jean-Pierre Girard à Carcassonne, je n'ai donc pas pu trop avancer sur le sujet

@APOC : oui la camelote chinoise marche bien, il sort la fréquence demandée, même si il y a un poil de friture sur la ligne (de très légère (mais légère) oscillation, de ferait une petite vidéo pour montrer ça).

Côté LCD1602, j'ai testé son fonctionnement à partir de l'arduino qui disposait d'une librairie pour interagir avec via le bus de données I2C, et ça marche.

Par contre chez moi l'affichage sera géré par le RaspBerry PI, et donc je suis en train décrire "from scratch" toute la librairie de gestion de l'affichage à partir de la doc constructeur.

J'ai d'ailleur publié une mise à jour de mon document avec les données récupérées car c'était pas simple, mais au final j'ai terminé l'implémentation de toutes les fonctions de base, il me reste à implémenter la création de caractères personnalisés (un peu comme Chercheur avec son icone de batterie qui indique le niveau de charge). Toute ma librairie est codée en java pour le RPI et est fonctionnelle, il ne reste plus que cette partie.

je n'ai rien fait d'autre pour le moment, car si Chercheur est une vraie fusée pour les prototypes, moi je prends mon temps

Voici la release 0.7 de mon document avec quelques modifications, notamment concernant le menu utilisateur et la partie implémentation de la librairie pour le LCD1602 :

https://drive.google.com/file/d/0B3VZSpIAFo...dit?usp=sharing

Pour tout dire, je dispose désormais de tout le materiel pour concervoir la partie physique, mais je ne commencerais l'assemblage que lorsque la partie programmation sera terminée Ainsi fonctionne le BlueDragon

Bon, quelques news :

- J'ai terminé l'écriture de la librairie d'affichage du LCD1602 via java sous RaspBerry en I2C. Il n'existait pas de librairie j'ai donc tout écrit à la main. Il me manque la partie des caractères personnalisés, mais je verrais ça une autre fois.

- Je viens de terminer ce que je voulais faire avec l'affichage de menu sur le LCD à savoir :
=> navigation au sein d'un menu (descendre, monter, selectionner) avec les vérification des extremité du menu
=> navigation au sein d'un sous menu
=> capacité de revenir du sous menu au menu
=> capacité à faire défiler les lignes d'un menu si celles ci sont trop grande et dépasse la taille de l'affichage

J'ai fait un code générique qui est normalement compatible avec l'ensemble des afficheurs de type HD44780 (donc les 1x 16, 2x16, 4x 16, etc.)

Voilà une petite vidéo qui paie pas de mine (j'ai coupé le son) :


Vous allez me dire : "c'est quoi ce bordel sur l'écran ??!!!".

Donc en gros je developpe avec Eclipse, qui me suit depuis que j'ai commencé à bosser sur le RaspBerry pour la cellule de Stanley Meyer. Le RaspBerry est là comme "ordinateur intelligent", et l'arduino pour interfacer l'intelligence programmée avec le monde electronique.

Le langage utilisé est le Java, car assez rapide à domestiquer et à utiliser. Il dispose d'ailleurs d'une librairie "PI4J" qui permet de communiquer en I2C via les GPIO du RaspBerry, I2C qui permet donc de relier le RaspBerry (RPI), l'arduino, l'afficheur LCD, et d'autres modules en I2C

Bref, Eclipse tourne sur mon PC Portable et je code tout depuis mon PC portable. J'ai ensuite ecrit un batch qui permet de recopier l'ensemble du code et des sketchs arduino à la volée sur le RaspBerry qui est sur le réseau intranet.

Une fois l'ensemble du code copié sur le raspberry, un script demande au raspberry de passer en "Remote Debug", ce qui permet en fait de rediriger tout le debuggage du code qui s'execute sur le RaspBerry, vers eclipse sur mon PC.

C'est la petite fenêtre que vous voyez enhaut à gauche ou défile plein de saleté d'information La dernière ligne "Arch = Arm" permet d'être sûr que le code s'execute bien sur le processeur du RaspBerry qui est un processeur Arm.

Bref, une fois la JVM en remote debug sur le RPI, elle attend une connexion depuis mon PC pour se lancer, à partir d'eclipse je lance donc le debug et voilou

Voilà voilà, la partie affichage des menus est fait. Il me reste à gérer les points suivants :

=> Gérer les "actions", c'est à dire que lorsqu'un sous-menu est selectionner, on doit rentrer dans une partie permettant à l'utilisateur de faire des choses. Par exemple, pour le menu Set DDS Frequency, il faut que je permette à l'utilisateur de rentrer la frequence du DDS qu'il souhaite.

=> Gérer les "boutons", à ce jour je teste les menus de manière programmé sans toucher un seul bouton. Ayant réussi à faire fonctionner le MCP23008, je vais donc commencer à interfacer la partie "bouton" avec le menu pour que ce dernier réagisse à une impulsion utilisateur

Quand ces deux points seront intégrés, je pourrait alors commencer à envisager de passer à la construction de deux ou trois choses et vérifier que tout se comporte comme il faut, à savoir :

1 - que lorsque la fréquence du DDS est renseignée par l'utilisateur, le DDS chinois envoie bien la fréquence désirée
2 - implémenter la fonction menu "show informations"
3 - Implémenter la fonction menu "Reset Arduino"
4 - Implémenter la fonction "Upload Arduino Sketch "
5 - implémenter le RTC sur le socle RPI + Arduino
6 - implémenter le DHT11 sur le socle RPI + Arduino
7 - implémenter le menu "Afficher Temperature / humidite"
8 - concevoir une sonde de tension et de courant pour la batterie
9 - Implémenter le menu "Afficher tension / courant batterie"

Ensuite on verra suivant l'avancée de Chercheur sur l'Ether-Metre => l'idée originelle était de pouvoir disposer d'une source de temps commune pour la prise de mesure en instantannée et pouvoir logguer tout ça sans brancher un oscillo.

Je suis habitué à travailler en mode "générique / modulaire", donc je passe beaucoup de temps initialement pour créer mes briques de bases, que je consolide, mais après la monté en puissance vers un autre projet n'est que du lego, et beaucoup plus rapide.

Raison pour laquelle je n'avance toujours pas sur l'aether-metre
Chacun ses défauts lol

Bonne soirée,

Hé bien moi qui construit un système de base pour permette aux gens de "débugger leur life", et même si je ne comprends pas toutes les subtilités techniques déployées, je trouve ton approche très pertinente. Je galère ferme encore et j'applique d'abord à moi-même mais après ça devrait rouler.
Bonne continuation.

Merci

Après toute une journée à coder,
Après avoir réussi des choses assez compliqué,
Un coup de gueule après les BUG Arduino inexplicables.

Ah oui il m'ont pompeusement agacé ces fichus bugs, j'en ai la fumée qui sort par mes narines de Dragon !

Je crois que le pire de tout pour un codeur, c'est de devoir debugguer sans outils de debugging, et de tomber sur des anomalies "d'un autre monde"... Un truc à devenir dingue ! une totale régression après 11 versions consécutive d'amélioration du code Arduino.

J'avais déjà eu des problèmes bizarre, commencé à toucher les limites de la bestiole, dû étudier l'impact des interruptions sur le code et son fonctionnement. Mais là c'est trop ! je jette l'éponge. Au moment où j'écris ces lignes, ce foutu Arduino n'est même plus capable d'envoyer la valeur d'une variable via I2C.

j'en ai un peu marre de devoir toujours courir, à l'aveuglette, pour devoir tenter de contourner des effets de bords invisibles, de tâtonner des heures entieres à essayer de comprendre de qu'il cloche.

Rah, l'Arduino aura eu ma peau ! J'en peux plus !
C'est une super plateforme lorsque le code est simple, lorsqu'il ne faut pas trop utiliser plusieurs librairies en même temps, lorsque le temps d'execution du code est compatible avec les interruptions I2C, mais là.... là c'en est trop.

La goutte d'eau qui a allumé le feu de Dragon, diantre, c'est vous dire à quel point il m'a gonflé !

Je vais donc garder l'Arduino pour le code générique que j'ai, très simple, qui permettait au RaspBerry de demander l'état d'une broche, de modifier l'état d'une broche, de demande la valeur d'une broche analogique, de modifier le PWM sur une broche.... et ce sera tout.

Tout ce qui nécessite l'utilisation de librairies comme le DHT11, le MCP23008, et dieu sais-je quoi encore, sera désormais par le RaspBerry, quitte à coder sa propre librairie. Pour avoir developpé ma propre librairie LCD1602, je peux vous dire qu'avec un peu de DOC, du temps, et beaucoup de debugging, c'est perdre bien moins de temps que d'essayer de debugguer un Arduino !

Donc voilà mon coup de gueule : Arduino c'est bien, mais dès que la logique programmative devient touchy (et encore.... rien à avoir comparé à mon code RaspBerry qui fonctionne comme une horloge suisse lui), ben il est hors de compétition. Alors ceux qui ont fait tourné des robots et je ne sais quoi avec Arduino, je leur tire mon chapeau, car ils ont dû en perdre du temps !

Seulement voilà, à ce jour s'acheter un RaspBerry qui n'a que 24 ports, ne sait pas gérer certaines fonctionnalités de l'Arduino (PWM entre autre), et y adjoindre un Arduino, ça commence à faire cher la solution (36 + 19 => 54€), surtout lorsqu'on voit des solutions comme BeagleBone (non testé).

Voilà, va me falloir réviser mon code maintenant.... moi qui venais de faire fonctionner superbement le MCP23008 avec Arduino...arf

Je compatis BlueDragon... Aller courage et persévérance...

les joies de la programmation, la petite paille qui vient jeter le désordre, tout reprendre du début pour vérifier,... ou?
mais quel bonheur quand cela fonctionne...
je n'en était pas du tout à ton niveau, mais je connais un petit peu...
courage, tu l'auras....

Merci de votre soutien

oui, mais c'est pas le tout , maintenant, il faut t'y remettre

je m'y suis remis... en faisant tout le ménage comme mentionné :)
Il me restera à faire les tests unitaires mais normalement tout est fonctionnel dans cette 12ième version. Et tout semble refonctionner correctement (chouette).

Donc pour rappel, l'objectif est de pouvoir piloter l'arduino depuis le RaspBerry PI qui est bien plus souple à la programmation complexe. Basé sur une communication I²C, l'arduino est pilotable par n'importe quel PC/Raspberry/BeagleBone ou autre machin qui cause en I2C.

Voilou :)

Bon, après de nombreux tests, et de retournage de ciboulo, j'ai abandonné le codage sous Java. Non pas que j'avais c'est pas bien, mais entre l'impossibilité d'avoir des entiers non signés, et puis la librairie PI4J qui fait des siennes, ou encore l'impossibilité de sentir que l'on maîtrise ce que l'on fait, j'ai dit stop.

Stop, Java pas bien, PI4J trop bizarre, et sans compter Arduino qui fait des siennes, c'était plus possible.

Donc j'ai fait table raze sur 5 mois de boulot (ça me trottait dans la tête depuis le 3ième moi mais je réussisais toujours à contourner les conneries). Table raze ou presque puisque je récupère quand même tout la reflexion et le boulot de conception qui a été mené. La perte sèche doit être l'équivalent de 1 mois de taff complet sur les 5.

Donc je repart, avec un nouvel environnement de dev, et une nouvelle façon de developper, en maintenant les mêmes possibilités qu'avec java :

- VMWare workstation, pour pouvoir disposer d'une machine virtuelle linux
- Linux Debian i686 3.2.51
- Eclipse CDT Kepler
- Cross tool chain Raspberry official
- C++0x (C++11)
- librairie WiringPI

Alors comment ça marche ce petit monde ?

VMWare workstation me fait tourner une machine virtuelle Linux Debian dans laquelle j'ai installé Eclipse CDT Kepler. Pourquoi Debian ? parceque c'est ma distribution préférée

Je developpe donc mon code sous Exclipse CDT Kepler dans la VM Linux, et compile grâce au "Cross Tool Chain". C'est quoi un cross tool chain ? c'est tout simplement la possibilité de générer un binaire qui n'est pas compatible avec votre processeur. En effet, ma VM a un processeur Intelx86, et le RaspBerry un processeur Arm. Les instructions sont totalement différentes ! donc on est obligé de passer par un cross tool chain pour compiler le binaire sur le intelx86 et ainsi générer du code lisible sur un processeur Arm.

"Mais pourquoi tu developpe dans une VM Linux sur ton PC Windows alors que tu pourrais installer tes outils de dev sur le RaspBerry et developper sur le RaspBerry ?"

Raison 1 => le raspberry n'a pas assez de mémoire, donc eclipse CDT sur raspberry, ça rame et c'est chiant
Raison 2 => le raspberry n'a pas assez de CPU, donc eclipse CDT sur raspberry, quand ça compile, c'est long
Raison 3 => il faudrait mettre un clavier et une souris + un ecran sur le raspberry pour developper, et vu les deux premières raisons, j'ai pas envie
Raison 4 => essayer de developper sur RaspBerry via du remote x-Windows, c'est pas jouable, ça rame
Raison 5 => j'ai essayé d'autres outils de dev sur raspberry, mais bon, je suis habitué à Eclipse

Donc voilà, me voilà repartit pour tout recoder, et cette fois en C++. Je peux vous assurer que ça fait drôle de repasser de java à C++, tant java est user friendly pour le developpeur. M'enfin c'est une habitude à réapprendre

Donc voilà les dernières nouvelles :
- Environnement de développement installé et paramétré
- objet de gestion de logs conçu et testé
- gestion des exception 'maison' conçu et testé
- implémentation de la couche I2C conçu et testé
- test de communication avec le sketch #12 de l'arduino (obtention de version) : réalisé et ajustements OK (conception du sketch #13)

A Faire :
- gestion du LCD1602
- gestion du DDS AD9850 via l'arduino
- gestion du MCP23008 pour l'interface homme machine
- implémentation des menu utilisateurs et des fonctions

Objectifs :
- pouvoir créer un petit générateur de fonction (sinus) à fréquence ajustable par des boutons et des encodeurs rotatifs.

Yop !
La récupération de mon code depuis Java s'effectue avec bon train et enthousiasme je suis content.

- J'ai pu transférer toute ma librairie perso du LCD pour l'affichage, bon p oint !
- J'ai pu transférer toute ma librairie de communication RaspBerry<=>Arduino via l'I2C, cool (il me faut faire les tests unitaires mais ça à l'air bon)
- je suis en train d'intégrer la fonctionnalité de gérer mon DDS AD950 en pilotage depuis le raspberry via l'arduino en I2C. il me faudra ensuite tester que la fréquence demandée est bien celle fournie par le DDS
- j'ai intégré un objet de log qui affiche le debug à l'écran et dans un fichier. Du verbose j'en ai chose que je n'avais pas forcément implémenté avec Java (cool pour debugguer )

ça avance ça avance ! Qu'est ce qu'il me restera à faire :

- gérer les menus avec le LCD (c'est à dire comme ce que j'avais fait sous java, avec la petite vidéo qui montre la fonctionnalité de déplacement d'une ligne trop longue)
- gérer le MCP23008 pour l'interface des boutons via I2C

puis passer à la construction d'un kit d'affichage / boutons pour permettre de mieux interagir avec les menus (1 LCD, 4 boutons, 1 encodeur et on verra )

Ahhhh, quel plaisir les amis de pouvoir avancer enfin avec du materiel qui fonctionne normalement ! si vous saviez comme c'est plaisant ! je regrette pas d'être passé au C++ (version 11). Parcequ'alors je developpe enfin les nouvelles fonctionnalités aussi rapidement que je le souhaite !

Nice shot
Je viens de finir d'implémenter la commande d'une fréquence depuis le RaspBerry vers l'arduino, et l'arduino l'envoie au DDS. pour rappel, la communication RaspBerry<=>Arduino se fait via I2C, et une sorte de registre que j'ai implémenté pour l'arduino (1 octet de registre et 2 octets de valeurs par registre).

Actuellement, il m'a fallu jouer du cerveau pour encoder 40Mhz (avec une résolution au hertz près) pour envoyer l'info dans les registres arduino. Du coup ça me prend deux registre pour se faire, mais c'est pas grave (quand on aime on compte pas), et j'ai désormais une précision du DDS au Hertz près depuis le raspberry PI.

Voilà donc un extract du debug côté RaspBerry, et du Debug côté Arduino.
J'utilise ces Debug pour m'assurer que ce que je veux envoyer est bien envoyé, et ce qui est bien reçu est bien ce que j'ai envoyé (c'est bête mais des fois ). Derrière sur Arduino j'ai un bout de code qui reconstruit la fréquence encodée en Mhz au Hz près.

Dans le screenshot çi-dessous, j'ai demandé la fréquence 12345678Hz (pour le fun). Et tout fonctionne :



Me reste à passer au garage et à brancher l'oscilloscope en fumant ma clope de la victoire pour vérifier que la fréquence générée par le DDS est bien de 12.345.678Hz (ou 12Mhz 345Khz et 678Hz si vous préferrez).

Mouahaha, Dragon bleu est Happy !
Bisous, m'en vait fumer cette clope bien mérité

Testé....et OK roh je l'ai appréciée cette clope lol







Dommage que l'oscilloscope ne permette pas de connaître la fréquence exacte du signal... il faudrait un FrequenceMètre je pense, au moins ça permettrait de valider le signal au hertz près ! On notera que l'oscilloscope lui, semble voir des petites variation de signal... un fréquence mètre permettra de jauger de la stabilité du DDS.

Voilou pour ce soir, bonne nuit !

FréquenceMètre commandé !
C'est un victor VC3165, de 0,01Hz à 2,4GHz.
Prix tout compris : 54€ environs



http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewIt...984.m1497.l2649

Cette bestiole me servira notamment à mesurer réellement et au hertz près, la fréquence de la sinusoide de l'AD9850. Je pourrais ainsi mesurer le taux d'erreur entre la commande (via le RaspBerry) et la réalité en sortie du DDS.

Bon côté code je viens de me rajouter un TimePortal, un peu comme on fait dans les jeux videos, c'est à dire que plutôt que d'utiliser des callback via timer, dans le loop principal, je défini la periode cyclique d'execution des fonctions (ex : refresh LCD toutes les 200ms) et ça me permet ainis de mieux gérer l'appel aux fonctions.

En gros, maintenant je peux appeller une fonction toutes les secondes, 200ms, ou autre, importe. Par exemple, dans le debug çi dessous, j'ai créé un timer perso de 5secondes. Lorsque ces 5 secondes sont écoulées, celà permet de modifier la variable qui conditionne le loop, et le code sort de la boucle.

J'ai également rajouté un compteur de FPS (très connu dans les jeux). Celà permet de voir combien de fois le code principal est exécuté. Actuellement c'est une mesure à vide, c'est pour celà que le chiffre est énorme. A terme, celà me permettra de savoir jusqu'à combien d'échantillon seconde je peux aller, par exemple en prise de tension, courant, etc.



==> le code dans le loop s'execute près de 17 000 fois par seconde. C'est normal, c'est presque à vide. Une fois chargé je devrais être situé plutôt vers les 500 fois par seconde si tout va bien.

[Note : je viens de réajuster le temps d'envoie des byte via I2C en direction de l'Arduino. Il semble qu'envoyer des byte trop vite vers l'Arduino fait que certains byte n'arrivent pas. J'ai donc rajouté une latence de 200µs entre chaque envoie, ce qui semble avoir stabilisé la chose]

Prochaines implémentations :
- Le défilement des lignes trop longues sur le LCD (maintenant que j'ai le timePortal)
- Implémentation des menus et de la navigation dans les menus + sous menus + selection
- implémentation des entrées utilisateurs [il va falloir que je me construise un shield qui ressemblera un peu à ça : ]



Sauf que la communication se fera en I2C avec l'écran, les boutons seront gérés par un MCP23008 et il y aura, j'espère, un bouton rotatif.

Il y a 2,5 ans, le Victor VC3165 était 10€ plus cher et à HK...

Maintenant il est disponible à Perpignan en Cataluña España


Il faut qu'il soit allumé 20 minutes pour se mettre en chauffe.
Ensuite il donne le résultat fiable au hertz.

Bonjour,

Intéressant ce fréquencemètre, vu le prix.

Quelle type de référence interne XO, TCXO, OCXO ?

Si c'est un XO, y a t-il moyen de brancher une référence externe ?

Ce qui permet d'augmenter le nombre de chiffres réellement significatif.

A+

JCV

Hello JCV,

Tu me parles chinois là avec ton XO, TCXO, OCXO tu dois faire référence au type de fréquence interne qui sert de référence. au pif je dirais TCXO parcequ'il faut 20min comme dit Gegyx pour qu'il soit stable [edit : je confirme le TCXO, c'est écrit dans le manuel : A crystal controlled temperature circuit provides constant compensation for temperature change thereby reducing measurement errors typically caused by temperature drift]

Je t'ai trouvé un post concernant l’intérieur de la bestiole. Pas de référence externe possible à première vue, donc c'est via un quartz embarqué.
http://electronicsjunk.com/?p=17

Le manuel : http://www.pira.cz/pdf/vc3165.pdf

Face arrière :


Le schematic (pas trouvé mieux) :


Bon comme dirais certains, '73' et XOXO

Dans la doc:

Time base
short time stability : ±3X10-9/second
Long time stability : ±2X10-8/month
Temperature drift coefficient :±1X10-7, 10°C ~ 40°C
Line voltage variation :±1X10-7 for line voltage±10%

Au vu des valeurs c'est bien un TCXO, donc très correct pour le prix.

Là on peut espérer avoir 7 chiffres significatif vrais.
Précision de 1Hz à 10MHz. avec une dérive de 0.2Hz par mois (= 2.4Hz par ans).

A+

JCV

Quand tu parles de dérives, tu parles d'une dérive à chaud, c'est à dire lorsque le FrequencyCounter reste allumé constamment non ?

Le Quartz a une ...... disons usure normale dans sa matière intrinsèque ,ce qui fait que l'horloge de référence subit une variation dans le temps , apparemment dans le schémas , il y a un CV de rattrapage , a ne surtout pas retoucher tant que l'appareil fonctionne correctement ...Mais l'usure du XTAL est donnée normalement pour un certain nombre d'heure d'utilisation , donc pas de soucis a se faire . C'est un bon petit appareil , peut être pas super -pro , mais très largement suffisant pour ton utilisation ..Pour le prix c'est une super affaire .....
Dans 5 ou 10 ans ,tu pourras faire une comparaison avec par exemple un géné DDS a 100 HRTZ et ensuite sur l'autre entrée a 50 MHZ au 1 HRTZ prés ..... et tu verras la variation ......

Sauf que une comparaison avec un DDS ne vaut pas plus que la référence qu'il a en interne.

Même si le DDS peut te fournir du 10MHz ajusté au 1/1000 de Hz, si sa référence n'est un simple quartz, le 10MHz ne sera vrai qu'à 10 voir même qu'à 50Hz près.

A+

JCV

Un quartz vieilli quand il fonctionne, en général plus il a fonctionné moins il dérive.

Dans le cas de ce fréquencemètre c'est la "Long term stability", qui est donnée par le constructeur à +/-2x10^-8 par mois (les 0.2Hz par mois pour une fréquence de 10MHz). On peut considérer que c'est pour un fonctionnement 24/24.

Effectivement (comme le dit Apoc) ne pas retoucher le CV de rattrapage, sauf à disposer d'un étalon de fréquence, pour faire ce qu'on appelle une calibration, celle ci à normalement était faite par le constructeur en fin de chaine de fabrication.

Comme dit Gegix, attendre une 20taine de minutes après mise sous tension pour que tout se stabilise en température.

A+

JCV

Merci pour les conseils et les infos !

L/C Mètre que j'avais commandé chez e_goto reçu ce jour (LC200A), commandé le 02/12 et reçu le 17/12 (boutique de HongKong).
ça fait deux commandes que je passe dans la boutique e_goto, et j'en suis satisfait. Les prix sont d'ailleurs très bon ! bravo à eux. Ah, et note importante : Frais de port gratuits

boutique :
http://stores.ebay.fr/icsprocessorsstore/

Hello,

Je viens de recevoir mon victor VC3165. Mauvaise nouvelle, je n'arrive pas à le faire fonctionner correctement. Je dois pas être très doué :/

J'ai laissé chauffé la bestiole 20 minutes, puis demandé au DDS de sortir 1500Hz, branché la prise BNC et les crocos sur des fils => les chiffres correspondent absolument pas.

J'ai changé les fils et la connectique, je suis passé à des pointes de touches avec une sortie en câble BNC. Toujours pareil.

Quand j'essaie de selectionner "fonction" ou autre, je n'ai pas ce qu'indique le manuel, je n'arrete pas d'avoir les chiffres qui défilent....

J'ai l'impression que mon achat est un achat foireux avec un materiel qui ne marche pas....

je verrais à l'oscilloscope si le DDS me sort bien la fréquence...

on peut voir sur cette vidéo :

ou celle là


Que dès l'allumage il y a deux lumières rouges qui s'allument :
- Freq
- Mhz

Chez moi elles restent éteinte. Quand j'appuies sur reset, elles s'allument bien, mais quand je relâche, walou.
Impossible aussi de modifier les "step" et de configurer le VC3165.

Quelqu'un a déjà eu ce problème ?

Bonjour,

J'ai bien peur qu'il soit en panne. Peut être quelque chose qui s'est déconnecté à l'intérieur pendant le transport, cela m'est déjà arrivé. Tout dépend si il y a des protections qui cassent la garantie en cas d'ouverture.

A+

JCV

Hello,

Je ne tente pas le diable. Je vois avec le marchand pour un retour...
Que les leds s'allument dans un cas et pas dans l'autre, ou que les boutons function ne fonctionnent pas me perturbe un peu.

Peut-être que c'est qu'un câble de l'interface qui s'est débranché, mais le type de problème me semble plus vicieux, comme un mauvais firmware.

A voir, j'attends les retour du vendeur.

Hello,

Je finis avec quelques information concernant mes tests d'hiers.
La journée ne fut pas très encourageante, le VC3165 n'étant clairement pas fonctionnel.

Je m'étais dit que le signal était trop faible, donc pour booster le signal en sortie du DDS AD9850, j'ai branché l'amplificateur que m'a fourni APOC.

Sur le VC3165 => N/A toujours même problème
Visualisation à l'oscilloscope sortit d'ampli => aucun signal, que du bruit
Visualisation en direct du DDS => que du bruit

Je me suis dit, "tient on dirait que le code arduino redeconne". Donc j'ai refait un sketch minimaliste pour tester le DDS, et rien ne sortait => il était HS.

Du coup, je l'ai remplacé par un autre de spare.
Visualisation sur l'oscillo en direct du DDS +> OK
Visualisation en sortie de l'ampli APOC => OK mais du jitter (le fameux jitter que j'ai sur le DDS)
Sortie DDS + Ampli sur le VC3165 => N/A toujours rien

et puis là je vérifie le DDS et je le trouve hyper chaud, ça sentait le chaud même. Du coup j'ai tout éteint et sortit l'ampli, puis retesté en sortie du DDS uniquement à l'oscilloscope => plus rien, que du bruit.

un deuxième DDS HS, un !
En fait, je pense que l'ampli d'APOC tire beaucoup trop d'amperage sur le DDS, en tout cas bien plus que les 25mA maximum préconisés ! Ce qui me flingue les DDS.

Du coup, j'ai branché mon troisème et dernier DDS.
Sur l'oscilloscope => OK
Programmation via le raspberry, visu sur l'oscillo depuis la sortie du DDS => OK

Donc synthèse de ma journée d'hier :
- Le Victor 3165 que j'ai reçu est défaillant
- L'ampli d'APOC tire beaucoup trop d'ampérage sur les puces DDS AD9850, ce qui les fait cramer. Il va me falloir trouver un pré-ampli qui ne consomme pas trop sur le DDS, comme a pu le construire Z sur l'ampli en courant, afin de l'interfacer sur l'amplificateur d'APOC.
- 2 DDS AD950 HS, reste un seul fonctionnel, il faudra que je me réapprovisionne

Jolie journée n'est-ce pas

Bonjour BlueDragon,

Hé oui, il y a des jours où tout va mal. Mais ça ira mieux demain.

A+

JCV