Recherche candidats pour développer une radio

[Invité]

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

[Invité]

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).

[HORNEX 4]

Salut

Je n'y connais rien de chez rien mais je trouve le projet top et te souhaite de le mener à bien ...

Pour le coup de main ...virtuellement je peux faire le café !

HX

[Invité]

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

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.

[Invité]

Salut,

une petite astuce pour les chips CMS : il faut les souder avec de la tresse a déssouder (paradoxal non ). 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

[RolluS 0]

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é 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

RolluS

[Invité]

Salut,

oublie la carte son. Tu ne pourra jamais faire de beaux signaux rectangulaire avec... deja essayé pour faire un géné de fonctions et le problèmes est qu'il y a une porteuse qui déforme les signaux.

Netsupra

[Invité]

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.

[RolluS 0]

Pour helico on ajoute les modes de vols, 2 à 4 sont courament utilisés...

Autorot

Normal/Démarrage

Idle1

Idle2

[Invité]

Bonjour,

il y a aussi:

gain gyro

regulateur de tours

coupure moteur

Maxence

[RolluS 0]

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

[Invité]

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

[Invité]

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...

[RolluS 0]

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 )

[RolluS 0]

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 et une sortie PPM pour rentrer sur un module spektrum...

[Invité]

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.

[RolluS 0]

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

[BertrandR 1]

Regarder par ici : http://pragmatec.net/catalog/2440SODIMM.htm

A+

Bertrand

PS : Je connais bien cette boite, c'est le moins que je puisse dire

[RolluS 0]

Merci pour l'info

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

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

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 , notament coté soft et interfacage

[Otatiaro 6]

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

++

[RolluS 0]

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...

[Otatiaro 6]

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).

++

[Otatiaro 6]

Re,

en developpement je connais pas (encore) C#

Si je voulais lancer une polémique, je dirais que si tu ne connais pas encore C#, c'est que tu ne connais pas encore le développement

++

[RolluS 0]

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

Merci pour les infos concernant le hard

RolluS

[Otatiaro 6]

Re,

Alors je vais pas apprendre le C# tout de suite

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 ...).