bonjour tout le monde,
encore un petit projet un peu fou puisque j'ai un peu de temps libre enfin.
je compte piloter via un nono d'autres nono en utilisant un rf434mhz.
je récupère des données via l'ethernet shield sur un server ou je le reprog a volonté en lui envoyant les données, il les parse, etc...
le problème que je rencontre est que dès que je mets dans le setup() les données pour le rf434, je ne peux plus recevoir les données via ethernet sur le nono.
// Initialise the IO and ISR
// vw_set_ptt_inverted(true); // Required for DR3100
vw_setup(2000); // Bits per sec
vw_set_tx_pin(3);
j'ai essayé toutes les pins de 2 à 13 rien a faire, je commente ces lignes et tout rentre dans l'ordre, mais évidemment plus moyen d'envoyer des données via rf.
comme d'habitude je dois passer a coté d'un truc tout bête, mais ou?
infobarquee:
bonjour tout le monde,
encore un petit projet un peu fou puisque j'ai un peu de temps libre enfin.
je compte piloter via un nono d'autres nono en utilisant un rf434mhz.
je récupère des données via l'ethernet shield sur un server ou je le reprog a volonté en lui envoyant les données, il les parse, etc...
le problème que je rencontre est que dès que je mets dans le setup() les données pour le rf434, je ne peux plus recevoir les données via ethernet sur le nono.
// Initialise the IO and ISR
// vw_set_ptt_inverted(true); // Required for DR3100
vw_setup(2000); // Bits per sec
vw_set_tx_pin(3);
j'ai essayé toutes les pins de 2 à 13 rien a faire, je commente ces lignes et tout rentre dans l'ordre, mais évidemment plus moyen d'envoyer des données via rf.
comme d'habitude je dois passer a coté d'un truc tout bête, mais ou?
merci d'avance
Les canards vont bien ?
tu a validé individuellement les différentes parties ?
reception 433 OK ?
ethernet OK ?
Tu a fait ensuite un bilan d'occupation des pins entre les modules ?
Quelquefois il y peu y avoir un "conflit de canard" 8)
je ----> []
Quel shield Ethernet ?
Normalement les shields Ethernet n'utilisent que le SPI
Le module RF c'est un bête module cablé à la main ou un shield ?
Apparemment tu a branché ton RF434 sur la broche TX(3) qui est aussi utilisée par Serial.
J'aurais soupçonné ca mais si tu as essayé d'autres broches ...
Peut être que le conflit de ressource est ailleurs ? timer ?
Il faudrait faire une passe sur le code des 2 libs pour savoir si elles n'utiliseraient pas le même timer ?
héhéhéhé toujours là quand un truc de malade se prépare
les canards vont bien et ils y en a même des nouveaux, mais pas nés ici.
oui tout les modules fonctionnes individuellement.
changement des cartes uno et ethernet.
si je désactive les 2 lignes pour le rf, tout fonctionne nickel.
dès que je décomente pour activer le rf en transmission, ben ca réceptionne plus les données en udp donc plus de traitement des variables.
et ceci même si le rf n'est pas connecté.
j'ai lu quelque part à un pb de timer entre l'ethernet et le rf, cela aurait il un rapport?
bonjour,
petit test ce matin, par acquis de conscience et miracle ca fonctionne.
si quelqu'un peut m'expliquer pourquoi?
cela voudrait dire qu'il y a une priorité?
le code bloque plus, a voir si les données sont bien envoyées par contre au récepteur.
au départ j'avais mis la conf du rf à la fin comme ceci
void setup() {
Ethernet.begin(mac, ip, gateway, mask);
Udp.begin(localPort);
Serial.begin(9600);
envoiip();
Serial.println("setup");
// Initialise the IO and ISR
vw_set_ptt_inverted(true); // Required for DR3100
vw_setup(2000); // Bits per sec
vw_set_tx_pin(3);
//vx_tx_active();
}
et j'ai inversé comme ceci, et ca fonctionne
void setup() {
// Initialise the IO and ISR
vw_set_ptt_inverted(true); // Required for DR3100
vw_setup(2000); // Bits per sec
vw_set_tx_pin(3);
//vx_tx_active();
Ethernet.begin(mac, ip, gateway, mask);
Udp.begin(localPort);
Serial.begin(9600);
envoiip();
Serial.println("setup");
La librairie ethernet n'utilise pas le timer1 normalement, UDP par contre je ne sait pas (je pense pas).
Il doit y avoir un registres qui est modifié par Ethernet.begin() et qui bloque vw_setup() par la suite.
Il faudrait comparé vw_setup() et Ethernet.begin() pour voir quelle(s) action(s) pourraient donner ce conflit.
bonjour tout le monde,
bon je bute sur un léger problème encore avec le rf.
je peux envoyer des données, mais il y a un maximum a ne pas dépasser en réception.
jusqu'a 27 caractères (123456789123456789123456789) pas de problème.
28 caractères = galère
y aurait il un moyen d'augmenter cette limite?
infobarquee:
bonjour tout le monde,
bon je bute sur un léger problème encore avec le rf.
je peux envoyer des données, mais il y a un maximum a ne pas dépasser en réception.
jusqu'a 27 caractères (123456789123456789123456789) pas de problème.
28 caractères = galère
y aurait il un moyen d'augmenter cette limite?
Bonsoir Infobarquee
il va falloir "cancaner" un peu plus sur le sujet
lien vers docs et refs 8)
si se sont des betes modules RF en E et R, ils ne sont pas en causes
!
ton probleme est peut etre du à un buffer soft qui sature , emission ou reception
il faut aussi voir ton code
salut Artouste,
alors je vais coincoiner un peu plus.
suffit de prendre les scripts d'origine http://forum.snootlab.com/viewtopic.php?f=38&t=399
bon je pense avoir trouvé le pourquoi du problème
0-255-60-199-60-124-60-99-60 ne passe pas,
on vire les -, ca passe
0s255s60s199s60s124s6s09s96s0 ne passe pas
donc, ce n'est pas un problème de nombre de caractères en fait, mais du mélange de type de caractère.
re test ce matin,
en mettant de a à z, soit 26 lettres, ca passe.
abcdefghijklmnopqrstuvwxyza soit 27, ca passe encore
abcdefghijklmnopqrstuvwxyzab soit 28, ca passe plus
donc, on est bien limité à 27 caractères pour envoyer en une seule trame des données.
si quelqu'un a uns solution pour repousser cette limite, je suis preneur, sinon je vais être obligé de faire une fonction pour découper les données et les envoyer une par une, et franchement, ca me COIiiiiinc un peu
infobarquee:
donc, on est bien limité à 27 caractères pour envoyer en une seule trame des données.
si quelqu'un a uns solution pour repousser cette limite, je suis preneur, sinon je vais être obligé de faire une fonction pour découper les données et les envoyer une par une, et franchement, ca me COIiiiiinc un peu
6.0 Implementation Details
Messages of up to VW_MAX_PAYLOAD (27) bytes can be sent
Each message is transmitted as:
• 36 bit training preamble consisting of 0-1 bit pairs
• 12 bit start symbol 0xb38
• 1 byte of message length byte count (4 to 30), count includes byte count and FCS
bytes
• n message bytes, maximum n is VW_MAX_PAYLOAD (27)
• 2 bytes FCS, sent low byte-hi byte
A voir si la charge utile max (payload) peut etre "facilement" changée dans la lib, voir avec les petits genies du code. 8)
voir eventuellement du coté de VirtualWire.h si ça peut etre résolu
// Maximum number of bytes in a message, counting the byte count and FCS
#define VW_MAX_MESSAGE_LEN 30 // <------------------
// The maximum payload length
#define VW_MAX_PAYLOAD VW_MAX_MESSAGE_LEN-3 // <--------------- 30-3=27
infobarquee:
j'ai déjà fait joujou avec la lib en modifiant dans VirtualWire.h
// Maximum number of bytes in a message, counting the byte count and FCS #define VW_MAX_MESSAGE_LEN 30 ====>100
// The size of the receiver ramp. Ramp wraps modulu this number #define VW_RX_RAMP_LEN 160=========>260
mais aucun changement
Il semblerait que ce soit du int8
static uint8_t vw_rx_buf[VW_MAX_MESSAGE_LEN];
et que ton 260 soit hors limite
A voir si c'est facile d'etendre la portée en passant juste les valeurs de 8 à 16
Artouste:
Il semblerait que ce soit du int8
static uint8_t vw_rx_buf[VW_MAX_MESSAGE_LEN];
et que ton 260 soit hors limite
A voir si c'est facile d'etendre la portée en passant juste les valeurs de 8 à 16
Artouste, le uint8_t s'applique au type de l'élément du tableau, pas à la taille du tableau.
la taille max d'un tableau est toujours un int (standard C)
Heureusement que tu peux faire des tableaux de 260 bytes
Artouste:
Il semblerait que ce soit du int8
static uint8_t vw_rx_buf[VW_MAX_MESSAGE_LEN];
et que ton 260 soit hors limite
A voir si c'est facile d'etendre la portée en passant juste les valeurs de 8 à 16
Artouste, le uint8_t s'applique au type de l'élément du tableau, pas à la taille du tableau.
la taille max d'un tableau est toujours un int (standard C)
Heureusement que tu peux faire des tableaux de 260 bytes
bonsoir barbudor
yep, j'avais survolé un peu trop rapidement !
bonjour,
n'empêche que, on ne peut envoyer que 27 caractères maxi en une seule fois, ce qui est franchement génant quelque part.
donc la seule solution pour le moment est d'envoyer une variable ou un petit groupe de variables sans dépasser les 27 fatidiques.
je suis en train de tester le module bi directionnel (merci snootlab en passant ) qui lui, peut envoyer/recevoir plus de caractères.
27 caractères pour envoyer des messages, c'est déjà pas mal.
Plus tu rallonge tes messages, plus tu prend le risque d'erreurs de transmission.
Mieux vaut couper en plusieurs petits messages bien protégés qu'avoir un gros message tout planté pour 1 octet frelaté.
barbudor:
27 caractères pour envoyer des messages, c'est déjà pas mal.
Plus tu rallonge tes messages, plus tu prend le risque d'erreurs de transmission.
Mieux vaut couper en plusieurs petits messages bien protégés qu'avoir un gros message tout planté pour 1 octet frelaté.
c'est certain, mais je n'envoie qu'au maxi 31 caractères, donc il m'en manque 4, snifffff
je me suis rabattu donc sur la solution d'envoyer chaque paramètre par groupe avec un marqueur de début et entre chaque paramètres pour les parser, dommage car ca prend plus de temps en traitement et requiert des conditions aussi.
question à 1Franc (nostalgie oblige et moins cher ) :
pourquoi avoir limité à 27 bits la transmission puisque c'est sur le principe du port série?
