Aller au contenu

Recherche candidats pour développer une radio


Messages recommandés

Bon, on va pas rentrer dans un débat long et inutile mais libre != gratuit.

Tout ce que fait microsoft est propriétaire même si quelques trucs sont gratuits.

Le mikroC de mikroelektronika est fourni gratuitement (il me semble, jamais utilisé, je programme mes PIC en assembleur) avec les cartes de développement de chez eux (easyPIC).

Disons que j'aurai bien été tenté par cette radio voire filer un coup de main, mais là, je vais pas pouvoir parceque je suis sous linux et plus globalement, parceque je pense qu'il faut que les projets comme le tien soient développé en libre car il ne peut être que plus bénéfique (performances, etc...) d'utiliser des outils libres.

Pour le PIC, tu le développes en C# comme indiqué dans le premier post :

pour la programmation du contrôleur il faut passer par du C# micro framework.

Ou en assembleur comme indiqué dans le dernier post

Netsupra

Lien à poster
Partager sur d’autres sites
  • Réponses 56
  • Créé
  • Dernière réponse

Les meilleurs posteurs dans ce sujet

Les meilleurs posteurs dans ce sujet

Images publiées

pour clarifier:

- le codeur, le satellite et le récepteur sont basés sur des PIC de MICROCHIP et les programmes sont développés en assembleur avec MPLAB. Sur chacune de ces cartes j'ai mis un connecteur pour une programmation ICSP.

- le contrôleur est basé sur le circuit de GHI-ELECTRONICS (cpu+écran tactile) et les programmes peuvent se développer à l'aide de plusieurs languages. Le seul point est qu'il doivent être écrit pour la plateforme .net micro framework. Par contre, rien n'empêche qui que se soit d'utiliser autre chose (le seul lien entre le contrôleur et le codeur est une liaison série)

- le programme CONSOLE (pour ma part, je vais commencer l'écriture en C# pour windows) n'est qu'un outil sur PC pour spécifier le comportement du contrôleur et du codeur: il transfert vers la radio un simple 'script'.

Note: si la taille mémoire du module GHI le permet je vais, dans un deuxième temps, essayer de me dispenser du PC. Mais c'est une plus longue histoire...

Dès que j'ai fabriqué et mis sous tension les trois modules et que je n'ai pas constaté de problème, je pourrais les proposer pour les amateurs de développement. Je les fais fabriquer à l'étranger et le prix n'est pas très cher (~50€ pour l'ensemble).

Lien à poster
Partager sur d’autres sites
  • 3 weeks later...

J'ai reçu les circuits imprimés et les composants. Voici une photo du codeur:

post-3885-1380088522,0554_thumb.jpg

seule difficulté, le microcontrôleur et ses 100 pattes. Pour ma part j'ai choisi la solution d'étamer au préalable le circuit imprimé et à l'aide d'une lampe loupe j'ai posé la panne du fer sur chaque patte.

Pour la mise en route je me suis juste amusé à allumer les led et envoyer au PC des octets par la liaison série: OK pour le moment. Reste maintenant la plus grosse partie: développer le soft.

Lien à poster
Partager sur d’autres sites

Salut,

une petite astuce pour les chips CMS : il faut les souder avec de la tresse a déssouder (paradoxal non :D). Ca va tout seul et en 2 minutes, c'est fait ;)

En tout cas, ca augure de bonne choses que tout marche. Peux tu mettre les schemas en ligne ? Pour filer un coup de main, je peux vérifier sommairement qu'il n'y ai pas un petit oubli.

Netsupra

Lien à poster
Partager sur d’autres sites

Salut, Je m'abonne !

J'ai moi aussi le projet de faire ma propre radio.

J'avais pensé au module XBee, tu as O24RCP chez qui tu aura pas mal d'info. Graupner a développé ses modules IFS autour du XBee, mais à abandonné je crois le IFS...

Je pensais moi utiliser un Netbook et interfacer un module 2.4Ghz classique. Il suffit pour cela de sortir une trame PPM par quelconconque sortie analogique, comme celle de la carte son par exemple.

Pour l'acquisition, une radio USB convertie avec des potard et manche de qualité ..

J'ai posé les idées sur le papier, mais jamais rien codé :P Pourtant a part la sortie son et le mixage/muxage, c'est pas insurmontable...

Je veux bien me joindre a toi pour ton projet si tu veux. A savoir, en developpement je connais pas (encore) C#, mais j'ai des idées :idea:

RolluS

Lien à poster
Partager sur d’autres sites

Je ne peux pas joindre le schéma (impossible à cause du format : XPS), je rappelle que tout le dossier est sur mon site http://www.legravier.com, page radio dans le carroussel (utilisez Internet explorer).

Je lance encore un appel: lorsque cette version du codeur sera au point, je fabriquerais une version 2. Toutefois, je pense qu'il y a beaucoup trop d'entrées. Pouvez-vous m'indiquer ce que vous utilisez habituellement sur votre radio, sachant que je conserve obligatoirement:

- 4 voies analogiques pour les manches,

- 8 voies numériques pour les trims digitaux.

Lien à poster
Partager sur d’autres sites

C'est plus souvent utiliser dans les modes de vols je pense

- 1 gain gyro par mode de vol

- 1 régime par mode de vol

Cela dit, certains aime parfois ajuster ces réglages en vols, et c'est alors des entrées analogiques.

Les maquetistes voudrons des entrées pour les feux, le train d'attero

Les avionneux voudrons des entrées pour les flaps, le train, les af

Les commandes présentes sur les radios actuelles, à l'heure de l'économie, ne sont pas la que pour être inutilisées ;)

Lien à poster
Partager sur d’autres sites

Salut,

Quitte à développer un ensemble RC, et vue la puissance de calcul disponible, autant penser à l'ensemble des fonctions déjà existantes sur les modèles actuels.

Un petit tour dans les notices de produits existants donne déjà un aperçu de ce que les dizaines de types de modélistes ont besoin, en fonction du modèle : avion, planeur, hélico, aile delta...

Une fonction très sympa serait la possibilité de gérer la commande progressive d'une voie, après activation d'un switch.

La progression pourrait être linéaire ou exponentielle, et s'effectuer sur une durée réglable.

Les applications : rentrée et sortie de train réaliste, sortie / rentrée des flaps, passage de mode normal à idle-up progressif sur la commande moteur... Brefs, les applications sont nombreuses !

On peut aussi imaginer des gérer des feux clignotants depuis le transmetteur.

En fait, ce qui est séduisant dans le concept d'une radio puissante, c'est de pouvoir déporter une partie de l'électronique habituellement embarquée, au niveau de la transmission, sous forme de fonctions gérées par le SW.

Les avantages : le gain de poids du modèle, le câblage simplifié, et bien sûr l'économie des modules embarqués.

Les inconvénients : le développement d'une interface utilisateur "user-friendly" qui permette d'utiliser et de programmer facilement ces options.

Autre inconvénient, c'est qu'il faut garantir un degré de fiabilité important à la transmission/réception, pour que l'ensemble des informations envoyées (dans ce cas plus nombreuses que sur une radio classique) soient reçues avec un très faible taux d'erreur. Mais quand on regarde la fiabilité des ensembles 2.4GHz, c'est finalement la moindre des choses ;)

Ce qui m'amène à la transmission des données.

Que ce soit un ZigBee ou autre, cela ne fait que définir le média, support de l'information.

Il reste à définir le protocole de communication, la procédure d'identification E/R et la gestion des erreurs dont dépendra essentiellement la fiabilité de la liaison.

Côté réception, pouvoir choisir entre une sortie PCM ou tout-ou-rien (de puissance ou pas), sur un nombre limité de voies, permettrait de piloter des feux ou des actionneurs non-proportionnels, sans ajout d'une électronique embarquée supplémentaire.

A+,

Fabien

PS : Je suis toujours dispo pour filer un coup de main ;)

Lien à poster
Partager sur d’autres sites
  • 1 month later...

Cela fait longtemps que j'avais donné des nouvelles, mais le projet avance tout de même. Je suis en effet sur un gros morceau: le codeur. Pour le moment, j'ai écrit les fonctions:

- gestion des liaisons séries (vers le contrôleur et le module XBEE, liaison fiabilisée par un contrôle CRC sur 8 bits)

- gestion du principe 'métronome': séquencement à interval régulier de l'envoi d'une trame vers l'XBEE

- prise en compte de 5 modes de fonctionnement (normal, programme, écolage élève, écolage maître, écolage transfert)

- acquisition des voies analogiques (avec correction en offset et gain) et numériques en tâche de fond (sur un séquencement de 10ms (réglable de 5 à 25), cette partie ne prend que 20µs)

Je suis actuellement sur la partie enregistrement des fonctions dans l'EEPROM, puis viendra ensuite l'éxecution des fonctions pour enfin générer une trame HF ou un signal PPM.

Note 1: suite aux remarques des lecteurs, j'ai opté pour la gestion de 12 voies.

Note 2: j'espère pouvoir présenter la notice du codeur pour la fin de l'année, mais le temps passe très vite, alors...

Lien à poster
Partager sur d’autres sites
  • 2 weeks later...

Bonjour, petit retour de mon coté sur le sujet...

Pour ma part, j'ai acquis un tablet pc sur base de pxa270, ce qui me permettra d'utiliser un noyau Linux temps réel, et des modules du noyaux temps réels basés sur ceux décrits ici: http://www.pabr.org/pxarc/doc/pxarc.fr.html

Par eilleur, quelle architecture as tu choisi legravier?

Pourquoi ne pas partir sur une Gumsticks comme le projet pabr, et y attacher le nettbook pour aller simplement lire et écrire les données, soits dans les devices soit dans le fichier de mixage..

Ainsi la gumsticks gère l'entrée stick / sortie ppm via un fichier de mixage définie avec ton netbook incluant ton ihm... Ca fiabilise le concept, et un pxa270 est largement plus rapide qu'une eeprom si je ne me trompe pas... (je connais pas grand chose en informatique embarqué, je suis juste un bon bidouilleur :P:mrgreen:)

Lien à poster
Partager sur d’autres sites

J'aurais mieux fait d'aler faire un tour sur ton site avant de répondre:

une unité centrale 'Embedded Master OEM Module' (ARM7 Processor 72MHz, 4.5MB Flash, 8MB RAM, beaucoup de moyen de communication avec l'extérieur dont, USB, série et SPI),

- un écran TFT de 4.5' (480*272 pixels) avec une dalle tactile.

J'ai pour ma part choisi un poil plus gros:

Pepper Pad 2

Mainboard 

• Intel XScale PXA270 CPU running at 624MHz, integrated RAM/USB/SD/keyboard controller 

• Intel 2700G7 2D/3D/video graphics accelerator with 704KB on-die memory, and 32MB dedicated VRAM (codename 'Marathon') 

• Philips USB1400BE audio/touchscreen/power management chip 

• 256MB onboard SDRAM (100MHz) 

• 32MB Intel StrataFlash boot FlashROM 

• Chrontel CH7013B NTSC/PAL TV signal encoder 

• IrDA and TvIR emitters/receivers 

Subsystems 

• Hitachi 1.8" 20GB MK2004GAL IDE hard disk (the same type of disk used in the Apple iPod) 

• GemTek WL-672 802.11b WiFi adapter, connected to mainboard via a CompactFlash port (spec sheet) 

• Infineon ROK 104 001/22R1A BlueTooth module with integrated antenna 

• Toshiba LTM08C355S 8.4" 800x600

En hard, manque le joystick USB :P et une sortie PPM pour rentrer sur un module spektrum...

post-11090-1380088620,6085_thumb.jpg

Lien à poster
Partager sur d’autres sites

Je voulais examiner plus précisement ta solution, mais par manque de temps, je me contenterais de te poser quelques questions:

- quel est le prix de cette merveille?

- quelles sont les liaisons possibles ? (E/S PPM, séries, entrées analogiques et numériques)

Note: dans ma solution, le codeur ne peut pas fonctionner tout seul. Il faut un PC ou un module externe pour le programmer. Alors ton bijoux peut être une alternative.

Lien à poster
Partager sur d’autres sites

Salut LeGravier ;)

Cette merveille n'est plus commercialisée et la boite qui le fabriquait est morte. à l'époque (en 2005) il était commercialisé dans les 700-800$, je l'ai touché d'occaz 150€ sur la Bay. Faut chercher sur le marché de l'occasion malheureusement.

C'est une architecture x86, sur un Intel ARM pxa270, et il existe aussi des Smartphone, PDA, UMPC, ou autre Tablet PC fonctionnant au tour d'un pxa270, même des produits actuels. Faut juste trouver une broche GPIO libre pour y faire sortir notre PPM..

Pour les Specs, voir mon message précédent..

Pour la communication: c'est le CPU pxa270 qui gère donc en natif le PWM (et donc PPM, PCM, DCM) sur broche GPIO (y'en à même de trop des GPIO pour nos projets). Question connectivité, faudra je trouve une broche non utilisée, ou que je sache router avec le Bridge du chipset vers un port physique existant... Il n'y a pas je pense de connectivité directe du pxa sur le boitier du pad, à part l'usb et l'infrarouge.

Va falloir opérer à coeur ouvert.

Pour ton projet, je t'invite à regarder de près le pxa270, notament de très près les cartes Gumstix: voir ici pour l'applicatif: http://www.pabr.org/pxarc/doc/pxarc.fr.html qui propose des modules temps réels pour le noyau linux et là pour le hard: http://www.gumstix.com/store/catalog/in ... Path=27_34 ...

Ca t'évite l'étape codeur..

Je vais très prochainement retravailler le code source de pabr pour faire des fonctions genre lire_joystick() ; mixer_signal() ; générer_PPM() en C++, donc compilable sur la Gumstick..

Je pense envoyer donc un PPM sur un module Spektrum. Peut être plus tard, j'utiliserait des XBee, pour le downlink, mais y'a beaucoup de code à rajouter pour fiabiliser la transmission. Si tu génère un PPM propre, les solutions commerciales (Spektrum, Futaba, voir Assan ou Corona) font très bien le boulot.. Mais le downlink fait parti de mon cahier des charge, et si en plus je pouvait faire redescendre un signal vidéo j'ai une idée très sympa..

Peut être un relais Bluetooth peut être une solution pour obtenir une porté en accord avec le modélisme..

Bon devellopements,

RolluS

Lien à poster
Partager sur d’autres sites

Merci pour l'info ;)

Pour le matos, je suis déjà équipé, mais les caractéristiques prix sont alléchantes :D

Pour l'expertise et l'assistance, vu le tarif annoncé je doute que je puisse me permettre de cliquer sur "contact" :D

Sinon le produit est sympa, mais ce site perso est trop commercial pour moi ;)

Par contre si tu veux (ou un mec de cette boite que tu connais bien veut) intervenir ici et donner des tuyaux pas de soucis :D, notament coté soft et interfacage :D

Lien à poster
Partager sur d’autres sites

Salut,

J'ai une gumstix overo water + palo43 + écran LCD 4.3" + accessoires a vendre si ca t'interesse ... j'ai aussi un ICD3 tout neuf même pas déballé.

Pour la partie HF je n'aurais pas utilisé de module XBee ... mais bon chacun ses choix ;)

Pour le .net µframework, la version 4.0 est sortie, avec pas mal de nouveautés et apparemment des perfs plus interessantes, j'avais commencé le portage du microframework sur PIC32 mais pas assez de RAM dispo et impossible d'interfacer sur une RAM externe (pas accès au bus mémoire).

Je confirme que la solution .net µframework + codeur séparé dans un µC est bonne, même si pas parfaite. Là ou tu peux révolutionner le truc, c'est dans le soft ...

De mon côté j'attend un NDA pour commencer a travailler sur PXA168 ...disont que c'est une autre gamme ;)

++

Lien à poster
Partager sur d’autres sites

Salut,

Je ne sais pas ce que Legravier va utiliser, moi je vais prendre du Spektrum pour le moment, pour valider l'aspect radio & soft de mixage et ne pas m'attarder sur la transmission.

Ensuite au choix:

- Module bidirectionnel avec signal montant type PPM (encapsulé) et downlink à définir

- Mise en réseau TCP/IP en UDP du TX et du RX (mais difficile de tenir le km de portée de mon cahier des charges).

Je n'ai pas d'idée de produits répondant à ces point à part les XBee. Qu'aurais tu utilisé pour la partie HF Otatiaro?

Pour la gumstix, je garde ton annonce sous le coude, même s'il me serait plus facile de développer (quand j'arriverais à la partie downlink) autour d'un pxa270 des 2 cotés...

Lien à poster
Partager sur d’autres sites

Salut,

Bonne idée pour le spektrum ...

Pour la partie HF, il y a pléthore de modules de communications bi-directionnels sur le marché, amplifiés ou non (et des amplis séparés aussi).

Par exemple, chez Texas Instrument, chez Nordic Semi, et y'en a un interessant, pas cher, et qui a déjà "fait ses preuves" (comprenne qui pourra ;) ), chez Unigen.

Sinon pour la gumstix, PXA ou OMAP, de toute facon tu vas compiler du C/C++ pour ARM via gcc sous linux, donc aucune différence sinon la puissance de l'omap par rapport au vieillissant PXA (sans compter la partie OpenGL ES, le co-proc, etc).

Si tu veux du PXA facile et pas cher, va faire un tour chez Toradex (modules colibri), c'est du PXA 3X0, mais ca n'a pas la puissance de l'OMAP3530, et de loin.

Pour l'émission TCP ou UDP, oublies, l'overhead est bien trop énorme pour avoir une transmission correcte, il faut utiliser des protocoles de bas niveau (et point to point, ou au pire multicast).

++

Lien à poster
Partager sur d’autres sites

Et t'aurais pas tord du tout ;)

Et comme tu as dis:

Sinon pour la gumstix, PXA ou OMAP, de toute facon tu vas compiler du C/C++ pour ARM via gcc sous linux, donc aucune différence sinon la puissance de l'omap par rapport au vieillissant PXA (sans compter la partie OpenGL ES, le co-proc, etc).

Alors je vais pas apprendre le C# tout de suite :P

Merci pour les infos concernant le hard :D

RolluS

Lien à poster
Partager sur d’autres sites

Re,

Alors je vais pas apprendre le C# tout de suite :P

Bah y'a mono sous linux, mais je dirais pas que c'est la solution "idéale", surtout si tu veux faire du temps réel.

Par contre l'interet de tourner sur un proc "couillu" genre PXA ou OMAP, c'est quand même d'être sur un OS évolué mais temps réel et des MIPS sous le pied, pour se passer du codeur séparé, et tout programmer en objet (impossible sur PIC)

++

[EDIT] Sinon t'as la solution Win CE ... là tu peux faire du C# mais pas en temps réel ... par contre tu peux mixer un process en C++ realtime et un process en C# IHM sur Win CE, c'est comme la solution de Legravier, sauf que ton codeur et ton controlleur ne sont plus deux processeurs, mais deux process sur le même processeur (ca serait encore plus drôle en dual core ...).

Lien à poster
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Les cookies sont des fichiers stockés dans votre navigateur dans le but de personnaliser votre expérience web. En acceptant notre politique en matière de cookies, vous acceptez que nous utilisions des cookies.Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.