Talkie PMR 446 mode data - Page 2

a moins que ce soit les autres qui changent a cause des perturbations. Ce
que je voulais simplement dire c'est que au niveau de la transmission il va
falloir trouver un moyen de securiser

C'est intE9%rE9%ssant comme projet, tiens-nous
au courant de tes dE9%veloppements STP !

Jean-Christophe a ecrit


bonjour

1ere phase de test "projet" avec en emetteurs 2 logicom FX700 acheté
sur etageres ;o)

- à ce stade generation aleatoire d'une trame de 10 octets utiles
(1 byte = id de l'emetteur
8 bytes : position geo)
1 byte check ... pour faire joli ;o) )

pour ne pas avoir à modifier physiquement les PMR (conservation des
caracteristiques "constructeurs et normatives" ) utilisation du VOX
(injection par prise mic) , cela necessite neanmoins un preambule
"mort" en debut de trame pour activer l'emission et etre sur de lancer
"on air" la trame complete .

pour l'instant essai en transmission en FSK "basique" en 1200
(condition labo, je ne teste que l'emission , la reception est assurée
par un "vieux 8546A" ;o) )

RAS ;o)

RvL

On Aug 3, 3:23 pm, "rvlegran"



Ca a l'air sympa comme fournisseur !



En cas de brouillage trE9%s localisE9% dans le temps,
un checksum peut s'avE9%rer utile pour jeter la trame
complE8%te afin d'E9%viter de logger des donnE9%es bidons.
Un CRC permettrait meme de corriger les erreurs E0%
la rE9%ception (sous certaines conditions) mais bon,
dans ton cas, pas possible de renvoyer un NACK.



Oui, sinon tu perds les premiers octets de la trame.
J'ai eu ce problE8%me avec un systE8%me de transmission
de donnE9%es via modem DSP sur une ligne dE9%diE9%e.
Mais ca se rE9%soud trE9%s aisE9%ment en prE9%fixant
la trame (avec 0x55 ou 0xAA pour etre E0% la
frE9%quence maximale de la sous-porteuse BF)



Tu m'E9%tonnes : sauf en cas de brouillage
industriel local, dans un labo tu ne risques
pas trop de problE8%mes de diffusion HF ...

Jean-Christophe a ecrit

oui , mais comme aurait dit Jean Yanne : "qu'est ce qu'on perd comme
temps en formalités" ;o)



retour "phase test 2" apres 30 heures+ : ;o)
- chaque emetteur envoie une trame 10 bytes identifiée et numerotée
croissante toutes les 30 secondes au top zero pour le 1er, au top +30"
pour le 2eme)
(pas d'injection de data GPS c'est juste à ce stade pour verifier le
taux d'echec de reception de trames)

les emetteurs en situation "pseudo normale"
test en zone tres urbaine bien bruité :oÞ

le recepteur (antenne tres bien degagée ;o) ) est centré sur un cercle
de test de rayon +/- 1km

1 des emetteurs etait positionné fixe à ~ 500 m du recepteur (mais pas
en  vue directe)

le 2eme "c'est balladé en journée" dans le cercle et ensuite positionné
à proximité du 1er.

retour :
sur ~3000+ trames emises (en theorie) par chaque emetteur
j'en ai "non receptionnées" :
-17 pour le fixe à demeure
-46 pour le "mobile" (dont grosso modo 2/3 sur la phase reelle mobile)

-2 cas de non reception de 3 trames successives (et bizzarement pour un
seul des emmetteurs alors qu'il etait à poste fixe avec son alter ego !
je remets l'analyse à plus tard ;o) )

- 5 cas de non reception de 2 trames successives.

Finalement à ce stade c'est plutot interessant comme evaluation.

La suite de l'evaluation à "la rentrée"
Je passe en mode "parking et pour quitter" ;o)

Rvl

On Aug 6, 1:39 pm, "rvlegran"



Soit au total un taux d'erreur de 2,3 % ?
Pour une appli professionnelle on exigerait mieux,
mais c'est pas si mal pour un premier test, je trouve.

Jean-Christophe a ecrit

ce n'est pas là un taux d'erreur, mais un taux d'echec ;o)
(pour le taux d'erreurs je verrais plus tard ! )


ça depend de la finalité des applis pro ;o)
une info On AIr fiable/verifiée/certifiée qui passe evacue le bruit.
apres il reste à savoir utiliser et caracteriser l'info.

recuperer une seule "trame" d'un dispo de loc est quelquefois suffisant
pour  "regler" un probleme de securité/secours

dans d'autres domaines la reactualisation (rafraichissement)
d'info de loc doit repondre à des contraintes "assumées"




Moi aussi ;o)
Je pourrais et sais faire bien mieux avec un budget de 5000+ ¤ par
poste unitaire !

Pour rappel, ça reste dans le cadre d'un "projet ludique/sportif" qui a
ses contraintes et defauts propres :
le cahier de specifs/charge est simple

les principales contraintes etant :
- pas (trop) cher
- facile d'emploi
- ne necessitant pas trois ans de formation
- ne pas reinventer la poudre

le defaut principal assumé etant :
- si ça marche pas pas tout le temps, c'est pas grave du tout !  ;o)

Rvl

On Aug 6, 2:51 pm, "rvlegran"

Ca m'intE9%resse : qu'entends-tu par "E9%vacuer" le bruit ?



Sans aller jusque lE0%, implE9%menter une simple liaison
bi-directionnelle E0% ~ 6 Kb entre le centre et les postes
permettrait de les interroger en rE9%itE9%rant automatiquement
les demandes en cas de trame non recue ou erronnE9%e (CRC)
Et mis E0% part le cout supplE9%mentaire d'un Tx/Rx
pour chaque poste (largement infE9%rieur E0% 5K Euro)
cela s'appuie essentiellement sur l'implE9%mentation
de software, via un protocole suffisament fiable
incluant la post-correction d'erreurs E0% la rE9%ception.



Oui, avec ca dans le cahier des charges, ca devient plus simple.
( & merci pour le feed-back de tes manips )

Bonjour à tous,

Mon message ne vas pas dans le sens des habitués du groupe.

Je possède une paire de PMR 446 que j'utilise régulièrement pour
transmettre quelques messages vocaux. Ils me sont très utiles lorsque
nous nous suivons en voiture (ce n'est pas moi qui parle), au ski, à la
mer, dans les grandes brocantes, etc...

Je me félicite que ces huit canaux ne soient pas envahis par des
transmissions de données automatiques permanentes, à toute heure du jour
ou de la nuit. Ce serait épouvantable.

Il existe des bandes spécialement prévues pour cela (433 MHz, 868 MHz,
2,4 GHz).

Un grand merci donc à l'ARCEP !


cordialement,


-----------------



Le 31/07/2010 13:34, rvlegran a écrit :