Reprise du message précédent :
Ce qui est génial, c'est que ce genre de chose se faire relativement facilement.
 
Bon, j'en suis pas encore là, je débute seulement, je teste 2-3 trucs
 
http://reho.st/medium/self/1c02d92 [...] cb45e4.jpg

Bonjour,
 
que pensez-vous de ce kit pour débutant à 17 euros ? :
 
http://www.gearbest.com/developmen [...] tml?wid=21
 

 
c'est une carte de marque "funduino", je ne sais pas ce que ça vaut,
 
merci

Si c'est vite livré, pourquoi pas.
 
Sinon, tu peux avoir n'importe quelle copie d'Arduino Uno ou Mega dans les 5EUR. Si tu y rajoutes quelques LEDs, boutons poussoirs/assortiments de résistances traversantes, peut-être d'autres trucs dont tu as besoin, tu peux t'en tirer autour de 10~20EUR, mais il faudra attendre 1 à 2 mois que ça arrive de Chine.

c'est sur un site chinois, les frais de port sont gratuits, le délai de livraison est estimé entre 15 et 35 jours

En réalité, on ne peut pas tirer de règle générale concernant les achats VPC chinois.
Parfois, ça met plus d'un mois à arriver, et parfois, en à peine 10 jours c'est là.
 
Et j'en suis certain, vu le volume de mes commandes là-bas    
 
En fait, si, on peut tirer une généralité : ne JAMAIS commander en janvier => c'est leur nouvel an
à eux, et là, les délais sont looooooooooooooooongs. Mais vraiment très longs.  

 
 
En bossant avec des chinois j'ai eut des remarque similaires vis à vis de la France   :
 
"En aout vous êtes tous en vacances, en décembre personne bosse et tous les vendredis vous êtes en RTT"  
 

Bonjour,

je suis intéressé par la technologie "RFID", est-ce qu'on peut faire des choses intéressantes avec le RFID et un arduino ?

par exemple :

- cloner les badges des entrées d'immeubles
- consulter le solde d'une carte de transport ( type pass navigo )
- consulter les infos d'une carte bancaire équipée de la technologie RFID
- fabriquer un porte-document virtuel à base de RFID, avec transfert des données via le RFID vers une mini carte équipée d'une mémoire de stockage

merci

Cloner, ça veut dire réussir à lire les différents secteurs donc avoir les clefs donc les cracker, en gros ^^
 
Apres RFID, c'est assez large, il y a plusieurs techno, le simple lecteur RFID de l'arduino ne permet de faire grand chose (bon tu peux détecter un badge spécifique et effectuer une action X, c'est sympa pour débuter).

Tu as cherché un peu avant de demander ?

Il y a plusieurs normes NFC/RFID, avec des terminaux différents et des sécurités différentes.

Cloner un badge nécessite généralement de cracker l'encodage de la puce, sauf s'il est tout pourri, c'est pas si facile.

Pour les CB, avec un bête Android ou lecteur ISO14443 tu peux lire les infos de la carte. Mais t'auras pas plus que ce que tes yeux te permettent déjà de lire. Le montant n'est pas dessus et il n'y a pas non plus le crypto de sécurité il me semble.

Pour le pass navigo, d'autres ont essayé apparemment : http://forum.frandroid.com/topic/5 [...] -tag-nfcv/ (premier lien de google)

En cherchant sur ce genre de problème tu trouveras de façon générale beaucoup de liens pour les téléphones Android avec support NFC, mais souvent documentés avec les détails sur les normes et l'encodage, et des PoC open source donc c'est une bonne base d'infos, même si Android ne t'intéresse pas.

Je suis à peu près certain qu'on a déjà discuté de NFC sur ce forum, essaie de retrouver le topic (c'est peut être au milieu d'un gros topic comme celui-ci)

j'ai un peu cherché sur le topic arduino avec le mot clé rfid, j'ai vu qu'un forumeur avait crée un montage à base de rfid pour sa porte de garage,

je suis un débutant en électronique, j'hésite en fait entre le rfid et le bluetooth pour mes projets,

j'ai l'impression que le rfid ne permet pas vraiment l'échange de données importantes de manière bidirectionnelle, et que le bluetooth serait peut-être plus approprié,

un de mes projets serait de créer un système permettant de dématérialiser le ticket de caisse papier que tout le monde connaît, l'idée c'est que le client aurait un petit boitier de la taille d'une carte de crédit utilisant les ondes radios pour communiquer avec un terminal à base de arduino, le client approche sa carte du terminal et le terminal lui envoie le ticket de caisse sous format électronique via RFID ou bluetooth ( la date, le nom du magasin, les articles commandés et le prix total payé ), et à la maison le client pose sa carte sur son propre terminal qui lui restituera vers son PC ( liaison USB ) le contenu du ticket de caisse virtuel, qu'un logiciel de comptabilité pourra exploiter

Heu, le RFID c'est pas un protocole de communication hein. C'est juste un "code-barre" amélioré

en gros tu veux dire qu'on ne peut pas utiliser le rfid pour transmettre une information ( qui peut varier ) à un périphérique ?

genre ( un exemple tout bête ) je veux envoyer la date et l'heure via un terminal RFID à un périphérique RFID, c'est pas possible ?

il reste alors le bluetooth et le wifi, mais on perd l'avantage du contact à faible distance, les informations vont aller rayonner au delà du nécessaire, ce qui est pas bon pour la sécurité et la confidentialité des données

edit : éventuellement il y a le protocole des rayons infra-rouges pour communiquer, une led infrarouge sur un terminal qui clignote selon un code et un récepteur en face à faible distance qui reçoit l'info

Non, tu peux pas stocker d'informations dans le tag RFID lui-même, c'est juste une sorte d'identifiant (mais qui fonctionne à distance, à la différence du code-barres).
 
La bonne nouvelle, c'est que vu ton projet, ça peut se faire quand même : les clients passent leur tag RFID quand ils passent à la caisse, qui va enrichir une base de données pour associer le ticket de caisse à l'identifiant unique RFID du client. Ensuite, quand ce dernier se connecte au serveur qui héberge ces données (via un logiciel par exemple), il peut consulter ses tickets de caisse de chez lui.

oui c'est une possibilité, mais elle a un inconvénient : ça oblige le client à avoir un compte chez le commerçant, il devra s'inscrire et donner ses coordonnées personnelles ( nom, prénom, adresse email, parfois obligation de souscrire à une carte de fidélité du magasin ),

le but de mon projet c'est de permettre à un client de faire un achat "anonyme" ( sans laisser ses coordonnées personnelles dans la base de données du commerçant ) tout en ayant un ticket de caisse dématérialisé, pour cela il faut que le client ait une sorte de petit boitier minuscule capable de recevoir par ondes (ou infra-rouge ) les données numériques du ticket de caisse dématérialisé,

le client place son petit boitier ( de la taille d'un badge ) sur le terminal du commerçant ( façon NFC/RFID ) et les infos de facturation sont transmises vers le badge, le client rentre à la maison et pose son badge sur son propre terminal relié à un PC --> le ticket de caisse est transmis au PC, données qui peuvent être gérés par un logiciel de comptabilité,

si ce projet devient un standard national ( ou international ) ça pourrait être adopté par tous les commerçants et mettre fin au ticket de caisse papier, le boitier "client" pourrait être subventionné par de la pub, des sponsors, il serait alors offert par les commerçants aux clients,

on pourrait aussi imaginer que le smartphone remplace le badge si le smartphone est équipé de capacités bluetooth/infrarouge et qu'il a une application adaptée pour le ticket de caisse numérique

Ha ouais, j'avais compris que t'avais un magasin que tu voulais équiper avec ton dispositif, pas que c'était potentiellement pour tous les magasins de la France entière  
 
Bin quand tu distribues le boîtier "commerçant", faudrait pouvoir le relier à internet, de façon à balancer les infos à ton propre serveur et pas à celui de l'enseigne. Et tu fais une interface web pour que le client récupère les données, formatées éventuellement selon le logiciel de compta qu'il utilise.
 
Le RFID ne peut pas stocker de données, mais c'est quand même beaucoup plus simple à utiliser qu'un boîtier USB (c'est juste une étiquette en fait, ça peut se coller n'importe où). Si tu veux vraiment un boîtier, faut qu'il intègre au minimum un protocole de communication + de la mémoire Flash + le port USB (et tout ce qu'il faut pour gérer tous ces éléments).
 
Par contre, je comprends pas trop comment tu comptes récupérer les données du ticket de caisse de n'importe quel magasin. Sachant qu'il doit y avoir une tétrachiée de logiciels de caisse enregistreuses différents, tu vas avoir du mal à faire un boîtier "commerçant" universel.

Euh si on peut stocker des infos dans les tag RFID. Il existe 3 types. Lecture seule, écriture 1 fois et écriture autant de fois qu'on veut.

Ha bah my bad, quand je m'y étais intéressé, j'avais vu que la fonction "tag identifiant unique"  
 
Du coup, tu peux stocker combien ? Et avec quelle technologie ?

Mouais, je viens de zieuter un peu les tags RFID avec mémoire, ça dépasse pas les 2 kilo-octets (ça viendra, mais à quel prix…). Donc tu peux effectivement y stocker la date et l'heure, mais un ticket de caisse ça va tout de suite être plus compliqué.
 
Je maintiens que la façon classique de l'utiliser, c'est juste comme un code-barre (avec éventuellement quelques infos sommaires en plus en mémoire, on est d'accord), qui interagit avec une base de données.

Il y a effectivement plusieurs types de tags, dont certains inscriptibles.  
Mais vu la faible capacité et les soucis de fiabilité de l'information, il vaut mieux éviter d'utiliser trop intensivement les tags réécrivables, surtout pour des trucs sensibles.
Faut pas oublier que le ID de RFID veut dire identification, c'est pas une clé USB hein. Et le NFC est un sous ensemble de la très vaste famille RFID...

Stocker sur les cartes, c'est une mauvaise idée, c'est rarement sécurisé proprement (et c'est pas franchement fait pour).

l'idée est d'avoir un porte document électronique pour stocker des tickets de caisse numériques quand on fait des achats dans un magasin physique,

en supposant que tous les commerçants aient adopté une norme commune pour le ticket de caisse dématérialisé ( qui n'existe pas encore, chaque commerçant utilise sa propre recette, en général ils mettent tout dans leur propre base de données maison, et c'est l'adresse email du client qui est utilisée pour envoyer le ticket de caisse au format PDF ),

la situation actuelle adoptée par les magasins ( leclerc, décathlon, boulanger ) n'est donc pas idéale en terme de respect de la vie privée ( ça oblige à communiquer ses coordonnées, adresse email, à être inscrit dans leur base de données, une sorte de flicage à chaque achat ) avec le risque d'être spammé sur sa boite mail ( cas vécu avec le magasin boulanger, ils m'ont bien envoyé le ticket de caisse au format PDF, et j'ai ensuite reçu plein de spams publicitaires de leur part pour des promos, un peu comme les prospectus papier des boites aux lettres ),

d'où mon idée d'un porte document électronique sous forme de carte/mini boitier qui tiendrait dans un porte clé, le client approche sa carte vers un terminal du commerçant, et ce terminal enverra un paquet de données numériques vers le mini-boitier du client,

ça suppose l’utilisation d'ondes type NFC/RFID ou bluetooth, ou bien une communication infra-rouge, et que la carte du client contienne de la mémoire ( type flash par exemple ) et un mini processeur,

il faut donc créer 3 objets :

- un terminal utilisant l'arduino ( relié au PC du commerçant ) dont le but est d'envoyer les données du ticket de caisse vers la carte du client

- la carte du client ( qui devra avoir une petite mémoire flash, un émetteur/récepteur NFC ou bluetooth ou infra-rouge, un petit processeur/micro-controlleur )

- un terminal arduino cette fois pour le client quand il voudra transmettre le ticket de caisse à son PC

Ne prend pas ça mal, mais j'ai l'impression que tu foisonnes d'idées tout en n'étant pas du tout à l'aise sur la technique.

Outre toutes les remarques sur la partie RFID, partir sur de l'Arduino pour un truc à cette échelle c'est pas du tout réaliste. L'Arduino c'est bien mignon pour faire joujou chez soi, mais pas pour un projet de cette envergure.

Je ne sais pas trop où tu penses aller avec cette idée mais si tu veux qu'elle aille quelque part, à mon sens il te faudra BEAUCOUP plus que les quelques conseils techniques que tu peux glaner sur un forum et du matériel amateur comme l'Arduino... Sans parler de toutes les questions légales sur la gestion des données clients, etc.

j'ai bien précisé que j'étais un débutant en électronique, sinon je ne viendrai pas demander de conseil d'achat sur un kit arduino ( cf mon message plus haut ), ainsi que la question sur la pertinence du RFID comme protocole de communication,

l'idée c'est pas de vendre une solution clé en main aux commerçant à base d'arduino, mais de créer ( du moins sur le papier ) une maquette de démonstration, voir si techniquement il existe une solution viable pour créer un ticket de caisse dématérialisé permettant un achat anonyme, respectant la vie privée,

pour l'instant la seule solution qui permet cela c'est un système de mini-carte/clé USB sans contact et une norme commune définissant le contenu d'un ticket dématérialisé, un projet qui n'existe pas encore, chaque commerçant s'obstinant à avoir sa propre solution maison utilisant une base de données où le client est obligé de s'inscrire,

je pense que pour comprendre la problématique du ticket de caisse dématérialisé il faut l'avoir vécu ( achète un truc chez décathlon, puis chez boulanger, puis chez leclerc, il va falloir à chaque fois s'inscrire dans leur base de données, donner son adresse email, avec la caissière qui met un temps fou à rentrer les données sur l'ordi qui lui sert de caisse enregistreuse... ), en l'état actuel des choses c'est la jungle, aucune harmonisation et pas de respect de la vie privée,

mon projet vise justement à résoudre ce problème de vie privée, avec mon système plus besoin d'être inscrit dans une base de données, le processus de transmission du ticket est entièrement anonyme, au lieu d'aller vers une adresse email ça ira via les ondes vers le mini-boitier du client, dans une mémoire flash

Je vois bien l'intérêt pour les clients, mais j'arrive pas à comprendre l'intérêt pour les commerçants par contre, qu'est-ce qui pourrait les motiver à utiliser ton système plutôt que de se constituer une base d'informations personnelles (qu'ils peuvent éventuellement revendre en plus) ?

peut-être une loi qui interdirait les tickets de caisse papier pour les achats en dessous d'une valeur de 50 euros, genre une loi pour l'environnement, protéger les arbres, limiter les déchets,

on a eu la même chose pour les sacs en plastique, qui sont interdits depuis plusieurs années, les grandes surfaces ont été contraints de s'adapter,

l'autre intérêt pour les commerçants : pas de rouleau de papier à gérer, c'est une corvée pour la caissière de changer le rouleau ( perte de temps pour le client ), et il y a aussi la problématique des composés chimiques du ticket de caisse ( bisphénol A, remplacé par d'autres composants dont on est pas sûr de la non-toxicité ),

ça évite aussi de faire une déclaration à la CNIL si le commerçant décide de ne pas avoir de base de données de clients,

concernant les bases de données il y a toujours le système de la carte de fidélité du magasin, qui permet d'avoir des points, des bons de réductions, ça ça ne disparaîtra pas de toutes façons, car les clients réguliers des magasins ( type mère de famille ) en ont souvent une,

à noter qu'un virage technologique a été complètement raté il y a 15~20 ans : celui du porte-monnaie électronique qui devait remplacer les pièces de monnaie et la carte bancaire pour les petits achats du quotidien, si ce projet avait réussi on aurait pu intégrer dedans cette idée du ticket électronique transférable via les ondes

https://fr.wikipedia.org/wiki/Porte [...] ectronique

Moi je pense surtout qu'à l'heure du smartphone, c'est plutôt un système basé sur ça qu'il faut envisager.
Le bluetooth ne fonctionne pas pour ce genre d'appli ( de ce que j'en connais ).
A voir pour le NFC.

+1, un attaquant aura tout le temps qu'il veut pour niquer les protections du tag si qqc de sensible est écrit dessus.

Le Calypso tiens bon quand même

 
Y a une puce dans les Navigo, et un coût assez élevé. Et c'est en partie centralisé. Craquer la carte a pas d'intérêt (ça servirait à rien) et la cloner marcherait mal vu qu'il y a une centralisation des accès.  
 
Ce qu'il propose c'est des applications à base de puces RFID basiques et à bas prix.

Au passage, le Bluetooth est encore moins pratique et adapté que le RFID pour le projet.  
 
Parce que pour effectuer une liaison, soit faut un appairage, forcément pas pratique, ou alors une liaison en BLE, mais c'est open bar. Et une liaison Bluetooth impose une batterie et un soft de chaque côté.

la liaison infra-rouge serait peut-être mieux adaptée pour échanger des données à courte distance sans authentification, il existe une librairie IR pour arduino pour transmettre notamment des données brutes ( via la fonction void sendRaw(unsigned int buf[], int len, int hz) ) :

https://itechnofrance.wordpress.com [...] r-arduino/
http://garagelab.com/profiles/blog [...] d-receiver

mais les smartphones n'ont en général pas de récepteur/émetteur infra-rouge

edit : certains modèles en ont finalement, probablement la partie émettrice :
http://www.akshatblog.com/list-of- [...] r-blaster/

je vais peut-être faire dans un premier temps un test avec 2 arduinos, tous 2 équipés d'un émetteur-récepteur infra-rouge, pour voir si un échange de données sans fil peut se faire à bonne vitesse, un message "hello world" transmis via infra rouge et qui serait affiché sur un écran LCD du coté de l'arduino "receveur"

pour stocker les données sur une carte mémoire on peut utiliser un composant "Micro SD Card Memory Shield Module" qui coute quasiment rien sur un site chinois :

http://www.gearbest.com/other-acce [...] tml?wid=21

je commence donc à avoir une bonne idée des pièces du puzzle de mon projet "porte-document numérique avec transmission infra-rouge des données", ça me semble faisable

un arduino relié à un PC qui fait office d'émetteur infra-rouge, et un autre arduino qui fait office de receveur ( et qui enregistrera les données sur sa carte mémoire flash ), la difficulté sera sûrement de mettre au point le code permettant de transmettre les bits via les diodes émetteur/récepteur infrarouge, il faut créer un protocole de gestion des erreurs, retransmettre les bits en cas d'obstacle qui interrompt le faisceau infra-rouge,

dans les années 90 ( avant la généralisation du wifi et du bluetooth ) on a eu dans le commerce des casques audio sans fil utilisant la transmission infra-rouge, puis des PDA/PC portables utilisant l'infra-rouge ( il fallait mettre cote à cote les 2 appareils ), il est donc possible en théorie de transmettre des grandes quantités de données via une diode infra-rouge, même si le procédé semble désuet maintenant face aux technologies à ondes radios, cela conserve un avantage : une meilleure confidentialité des données car le piratage n'est possible que si on se trouve face à la diode infra-rouge

Dans l'immédiat oublie ton idée de porte document.
Fait toi un petit montage pour jouer avec les arduino et voir ce que tu arrives à en tirer.
 
Pour ta liaison infrarouge c'est tout simplement une liaison série RS-232, au lieu d'avoir un fil tu as deux diodes de chaque coté, une qui émet et l'autre qui reçoit. Pas besoin de créer un protocole.

Oui enfin le risque d'erreur de transmission est bien plus élevé en IR qu'en RS-232, pour garantir l'intégrité des données il est nécessaire d'utiliser un protocole un minimum robuste par dessus la couche physique.
 
Après pas besoin de réinventer la roue, du TCP over UART et hop  

 
 
Moi aussi je cherche un starter kit pas trop cher    J'ai trouvé celui-là : https://fr.aliexpress.com/item/OSOY [...] 48109.html Ma question : quels pdf en français (où même livres) vous recommandez pour débuter avec ce matos ? J'ai trouvé ça : http://astenor.free.fr/Arduino/ (la liste des composants semble être la même que sur aliexpress) mais j'ai l'impression que certains chapitres ne sont pas dispos  

si tu es un débutant complet en électronique alors il y a ce tutoriel ( consultable en ligne et téléchargeable ) :

https://zestedesavoir.com/tutoriels [...] embarquee/

et ce blog qui est bien aussi :

http://eskimon.fr/ebook-tutoriel-arduino

il faut pas se limiter à un seul tutoriel, ni un seul bouquin papier, les sources d'infos sont très nombreuses sur internet, tu tapes le mot clé qui t’intéresse dans un moteur de recherche et ensuite tu pioches parmi les résultats, et si ça bloque toujours tu peux poser des questions sur les forums dédiés à l'arduino

Merci   En fait c'est pour offrir à quelqu'un et je pense qu'il sera + motivé s'il a un seul livre/doc qui détaille quelques montages possibles avec les pièces du kit. Je vais regarder tes liens.

 
 
Presque deux ans après, je reviens sur mon projet.
 
Mais j'ai de gros problèmes d'alimentation avec (entre autre) le schéma ci dessus, et comme je suis une bite en électricité...
 
J'utilise une alimentation de pc pour fournir le courant d'alimentation des composants (plutôt que l'arduino).
 
Pour cela je branche un câble rouge sur le rouge d'une molex et un noir sur un des noirs de la même molex, et zou, du 5v à foison, normalement.
 
Problème :
 
Si je branche un capteur de distance (à ultrason), tout va bien. Il affiche les bonnes distances et ne bouge pas.
 
Si j'ajoute une matrice de led 8x8 en dérivation, patatra : les distances sont très incorrectes (3 ou 4 fois moins par exemple) et varient fortement.
 
Dès que j'ai plusieurs composants ensemble (j'essaie de mettre un servomoteur notamment), ça finit par merder :
-> Le capteur de distance s'embrouille
-> Le moteur refuse de bouger
-> La matrice led peut éventuellement ne pas s'allumer
 
 
C'est pas un soucis de code, de collision d'infos ou autre, parce que si par exemple j'alimente le capteur de distance sur l'arduino et la matrice sur le 5v de l'alim de pc (ou vice versa), pas de soucis. En dérivation sur la même source, bim.
 
En testant à l'ampèremètre, ça baisse beaucoup même avec deux composants (et c'est sans doute normal vous allez me dire, mais encore une fois, je suis une quiche en électricité).
Chaque composant seul se comporte normalement.  
 
Mais avec une alimentation de pc capable de délivrer jusqu'à 16 ampères sur le 5v, j'espérais au moins pouvoir alimenter correctement un pauvre capteur de distance à ultrason et une minuscule matrice de led.
 
(Et idéalement, 6 petits servo moteurs avec ça )
 
 
What am I doing (terribly) wrong?
 
 
(J'ai pensé aux câbles et aux breadboards aliexpress, j'en ai changé par ceux d'un kit Sunfounder, idem. Là j'fais avec le moins de câbles possibles et une seule breadboard de qualité pour mes tests)

 

 
Ça peut aussi être ta matrice de LEDs (balayage ou PWM) qui fonctionne à la même fréquence (ou une harmonique) que ton télémètre.

Pas trop compris où/pourquoi placer des condensateurs, mais la partie sur la fréquence de la matrice m'a aidé dans un premier temps, j'avais réussi à trouver une configuration qui fonctionnait assez bien :
 
-> Deux servos et la matrice led en dérivation sur un circuit 5v alimenté par l'alim
-> Le télémètre sur un circuit 5v alimenté par l'arduino (branché en usb)
 
Hélas, dès que je branchais les autres servos, patatra, impossible de les bouger, ils bloquaient en gémissant.
 
 
Mais j'ai trouvé la solution, par pure chance :
 
http://forum.arduino.cc/index.php?topic=269409.0
 

 
Il fallait "juste" connecter le - du circuit de l'alimentation externe au ground de l'arduino, avec un câble, et direct les 6 servos ont tous réagi au quart de tour.
 
Je continuerai plus tard mais je suis heureux.    
 
Ca a à voir avec le pwm des servos (le seul lien avec l'arduino) j'imagine? Le servo se base sur l'état du courant qui le traverse pour comprendre l'info du pwm et sans cette connexion au ground de l'arduino, l'info était erronée, je crois.
 
Vais étudier tout ça demain, merci en tout cas.
 
 
Edit : Mais j'suis trop con en plus il y était, ce câble, sur mon premier schéma.

 
Peut-être que ton problème ne vient pas de l'alimentation mais j'ai déjà eu un souci en faisant cohabiter plusieurs librairies qui avaient chacune besoin du même timer... Tout fonctionnait bien unitairement mais une fois ensemble c'était la cata !