Talkie PMR 446 mode data

C'est int=E9r=E9ssant comme projet, tiens-nous au courant de tes d=E9veloppements STP !

Reply to
Jean-Christophe
Loading thread data ...

Certes, mais je ne vois pas ce qu'il peut y faire, sauf changer de canal jusqu'=E0 en trouver un qui ne soit pas (trop) occupp=E9 ?

Reply to
Jean-Christophe

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

--

Alain
Reply to
alain denis

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

Reply to
rvlegran

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

Ca a l'air sympa comme fournisseur !

En cas de brouillage tr=E9s localis=E9 dans le temps, un checksum peut s'av=E9rer utile pour jeter la trame compl=E8te afin d'=E9viter de logger des donn=E9es bidons. Un CRC permettrait meme de corriger les erreurs =E0 la r=E9ception (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 probl=E8me avec un syst=E8me de transmission de donn=E9es via modem DSP sur une ligne d=E9di=E9e. Mais ca se r=E9soud tr=E9s ais=E9ment en pr=E9fixant la trame (avec 0x55 ou 0xAA pour etre =E0 la fr=E9quence maximale de la sous-porteuse BF)

Tu m'=E9tonnes : sauf en cas de brouillage industriel local, dans un labo tu ne risques pas trop de probl=E8mes de diffusion HF ...

Reply to
Jean-Christophe

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

Reply to
rvlegran

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.

Reply to
Jean-Christophe

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

Reply to
rvlegran

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

Ca m'int=E9resse : qu'entends-tu par "=E9vacuer" le bruit ?

Sans aller jusque l=E0, impl=E9menter une simple liaison bi-directionnelle =E0 ~ 6 Kb entre le centre et les postes permettrait de les interroger en r=E9it=E9rant automatiquement les demandes en cas de trame non recue ou erronn=E9e (CRC) Et mis =E0 part le cout suppl=E9mentaire d'un Tx/Rx pour chaque poste (largement inf=E9rieur =E0 5K Euro) cela s'appuie essentiellement sur l'impl=E9mentation de software, via un protocole suffisament fiable incluant la post-correction d'erreurs =E0 la r=E9ception.

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

Reply to
Jean-Christophe

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.