87.5mhz(réponse) - Page 3

multiple de 7? de 9 ? de 10? 11 ?

-

Bon, j'ai regardé un peu, c'est bien du trinaire à 1200 bps... Par contre j'ai regardé un des morceaux, et il consiste simplement d'un même message répété 13-14 fois...

Ca fait 32 symboles trinaires, "-===+-+-+==-+=-==+====-=+=-+-==+" (= : peu de variation, - : front descendant, + : front montant) ; c'est un peu limité pour faire quoi que ce soit, comme données

du #trinaire# si t'as pas lu la norme de ce signal tu pourras pas le deviner, pour moi ca n'existe pas.

Vous ne devez pas regarder la variation générale d'amplitude du signal, elle correspond à la fréquence parasite 50Hz du secteur, normalement les bosses doivent toutes avoir la même amplitude. Faudrait un passe haut qui ne laisse passer que >100 Hz

Donc "peu de variation" = PAS de variation

il y a deux sortes de codages pour votre information: soit niveau = bit dans ce cas _-_-__-- ca fait 01010011
mais OK il est possible d'avoir un codage par transition dans ce cas 0 = pas de transition, 1 = transition et_-_-__-- ca fait 1111010. Le codage reste binaire.

c'est les deux seuls trucs utilisés en codage simple. Je pencherai fortement pour le premier cas. Un trinaire ne serait vraiement pas intéressant en plus, si on réfléchit un quaternaire est beaucoup plus intéressant puisqu'il permet la transmission simultanée de 2 bits.
Croyez moi ou pas, mais trinaire c'est impossible.

Voici un document pour appuyer ce que je dis

voici un TRONNN telquel dans le fichier lorient.mp3



Voici le même endroit après passage par un filtre FFT qui coupe tout ce qui est en dessous de 100 Hz:



Comme vous voyez, aux erreurs de transmission près, il suffit de regarder qui est en dessus de zéro d'amlitude pour trouver les bits un!

Moi je lis donc après le dernier bit positif de synchro:

00111100110100100010101110110000111101010010011100001110010111101111 etc...
pour être plus précis faudrait mesurer la largeur exacte des bits.

-

Nan mais bon squalyl j'avais déjà décodé le trinaire avant de lire ton message

Bon alors je commence les explications (partielles, j'ai pas eu le temps d'aller plus en détail hier soir) :

Codage physique
Tous les 1/1200è de seconde, on a un symbole trinaire : le signal baisse soudainement (symbole N comme Négatif), bouge peu (symbole E comme Egal), ou monte soudainement (symbole P comme Positif).
Evidemment, pour pas que le signal prennent des valeurs trop grandes, un filtre passe-haut est appliqué.

Encapsulation
Un "trooon" est constitué successivement :
* d'un quasi-silence pour dire de faire attention à la suite
* d'un sinusoïde à 600 Hz pour synchroniser
* des données trinaires elles-même
(on peut assimiler le sinusoïde à la suite trinaire PNPNPNPNP...)

Si on convertit tout ça en trinaire, on obtient quelquechose de la forme :

<sync> <start> données

où
<sync> = (PN)*
<start> = PEEEENEPENPNEPNEEEPNPNPEENPENEEE

Les signaux se présentent sous l'une des deux formes :

Frames type A
Ils sont de la forme :

<sync> <start> <channel0> <channel1> ... <channel15>

avec <channelX> un mot de 32 symboles
Pour une valeur de X donnée, <channelX> ne décrit que peu de valeurs différentes, du moins dans le court extrait qu'il y a.
Dans la plupart des frames, quasiment tous les canaux sont tels que <channelX> = <void>
avec
<void> = PEEENPNPNEEPNEPEENEEEEPENEPNPEEN

Je ne sais pas à quoi c'est censé correspondre, mais il se pourrait que les canaux correspondent à différents services, et les <channelX> à un état donné du service. C'est très très probable que les <channelX> ne contiennent pas l'équivalent de 32*log(3)/log(2) bits d'information, mais bien moins (code de redondance cyclique).

En fait, sur toute la durée du signal, il n'y a que 9 valeurs distinctes de <channelX> différentes de <void> ! Ca veut sans doute dire "tout va bien".

Frames type B
Ils sont de la forme :

<sync> <start> <data:val0> <data:val1> ... <data:val3> <start> <data:val4> <data:val5> ... <data:val7>

avec <valX> un mot de 16 symboles
et
<data:Z> = <void> <datam> <Z> <datam> <Z> <void>
<datam> = PEEEEEEEEEENEEEE

C'est probable que les <Z> soient moins redondants que les <channelX>, parce qu'ils sont déjà dupliqués pour vérifier les erreurs ^^
En tout cas c'est encore plus bizarre : il y a 6 frames de ce type, mais tous contiennent exactement les mêmes données <valX>





Bref, il y a vraiment très très peu d'information là-dedans : il y a 8 <valX> différents (128 symboles), mais qui n'ont pas changé de tout le signal ; et il n'y a que 9 <channelX> distincts (256 symboles), et seulement 5 valeurs de X où à un moment il y a eu un <channelX> != <void>.
Ca veut dire que sur plus d'une minute d'enregistrement, il y a de l'ordre de 384*log(3)/log(2) = 608 bits = 76 octets de vraies données... (et probablement moins si on tient compte de la redondance, et du fait que sur un temps plus long il n'y aurait pas 2x plus de données) C'est un peu maigre

Pour en tirer qqch d'intéressant il faudrait faire des enregistrement plus longs, par exemple quelques heures...

-

qu'est ce qui te dit que ce sont les transitions qui sont significatives et pas les états ? Pour moi sample > 0 = 1; sample <0 = 0

Rien du tout, d'ailleurs effectivement je n'avais pas regardé en détail mais l'absence de séquences "P[^N]*P" ou "N[^P]*N" fait que tu peux, de manière bijective, transformer "PEEENPNPNEEPNEPEENEEEEPENEPNPEEN" en "00001010111011000111110011010001" (et ça marche bien puisque tous les découpages interviennent à des endroits qui vérifient la regexp /(?<=N[^P]*)/)

Ca ne change rien à ce que j'ai dit, en tout cas Et en plus ça montre que l'implémentation peut considérer indifféremment le signe du signal ou la direction du dernier changement ^^

mais qu'est ce que tu ramènes une regexp là dedans

Un bit est un niveau selon le codage le plus simple.

A quoi peut servir un codage par transitions? A "hacher"le signal pour augmenter sa fréquence et faciliter sa transmission par radio.

Ca, OK.

Mais moi quand je vois les grands espaces sans transitions au milieu, je penche plutôt pour un codage par état plutôt que par transition, et je t'assure, c'est beaucoup plus facile à décoder pour un machin électronique.

Oui, encore que pour un codage par état ça signifierait qu'il y a une séquence de sychronisation quelque part.

(filtré > 100 Hz à partir du curseur)

ca suffit tu crois ?

On va dire que oui

squalyl^2 :
mais qu'est ce que tu ramènes une regexp là dedans

Un bit est un niveau selon le codage le plus simple.

A quoi peut servir un codage par transitions? A "hacher"le signal pour augmenter sa fréquence et faciliter sa transmission par radio.

Ca, OK.

Mais moi quand je vois les grands espaces sans transitions au milieu, je penche plutôt pour un codage par état plutôt que par transition, et je t'assure, c'est beaucoup plus facile à décoder pour un machin électronique.

Ca dépend de quels machins électroniques.
En plus, les niveaux ne sont vraiment pas propres...

squalyl> justement, regarde les transitions "sales" à certains endroits : le signal oscille près de 0, mais sans transition brusque ; je pense qu'il ne faut pas les compter comme changements d'état, justement... (c'est bien trop sensible à plein de perturbations -- par exemple des parasites basse fréquence) D'ailleurs si tu regardes x[n+1]-x[n], tu verras que les transitions sont très, très nettes ^^

Le pbm c'est que vous analysez un signal qui a été décodé comme un signal FM alors qu'il peut s'agire de tout autre chose
N'oubliez pas qu'il a été enregistré a partir d'un poste radio dans la bande FM, si le signal original est en modulation d'amplitude, vous faites quoi ?

rien d'interessant, idem si le signal est codé en modulation de phase

c'est vrai ça.

Mais enfin ca a une bonne geule de signal démodulé et décodable, quand même

si ce signal a été envoyé dans cette bande de fréquence c'est ptet pour pouvoir être démodulé à partir d'une radio fm, avant d'être décodé non?

Euuuuuh Godzil on obtient pas du bruit mais un truc à pile 1200 bps (coïncidence ) et avec pile une structure pas entièrement triviale mais tout de même hyper répétitive... Je vois pas ce que tu peux vouloir de plus

mes souvenirs sont lointains mais en démodulant en fréquence un signal modulé en phase on obtient me semble-t-il des fréquences semblables (multiples de la fréquence d'origine...) mais un signal différent.

euh ouais peut être

En attendant moi je continue.

On a un signal à 1200 bauds? On verra mieux en resamplant le signal à , disons, 4800 Hz, manière d'avoir disons... 4 échantillons par bit, on va les compter ensemble si vous voulez (pour être gentil j'en ai mis 1 sur 4 de rouge) ...



Je ne sais pas ce que vous voulez de plus clair, il y a exactement des groupes de 4 échantillons alternativement hauts et bas, et par hasard chaque transition se fait juste avant un point rouge.

Ce qui nous donne donc:

010101010100 // 111110011010010000101011

La perte d'alternance 10 produit le départ du message, donc il commence après le double zéro:

Je suppose qu'il n'y a qu'un bit de start, etc...

le message le plus plausible est donc:

1111 1001 1010 0100 0010 1011

F9 A4 2B ...

Après faut savoir ce que ca veut dire...

-

Euh, c'est à me demander si vous avez lu mon message où j'expliquais le protocole

Extrait de mon décodeur : s/11111001101001000010101110110000/< strt >/g;
C'est le début du message <start> ...

Evidemment l'image correspond

Qu'est ce que tu ne comprends pas?

Que certains bits 1 soient proches du sample 0 ?

Je suis en train de le faire, le programme de décodage, mais c'est long.

Remarque que tous les fronts ont la même amplitude. La décroissance exponentielle est dûe à la nature électronique de la transition. Elle ne rentre pas dans le code.

Pollux > Tes explications sont FAUSSES du début à la fin.

Tu maintiens que c'est du "trinaire" ??? Alors dans ce cas expliques moi:

- comment tu codes PPPPP ou NNNNN ? Ce code n'est pas impossible en théorie, on devrait statistiquement le rencontrer dans le message.

- comment expliques tu justement l'absence de cet enchainement?

D'autre part si ton code trinaire est bijectivement associable à un code binaire, il n'est PAS trinaire. il est binaire. Tout simplement.

Le signal est *représentable* en trinaire, ce qui ne veut pas dire que n'importe quelle chaîne trinaire pourrait être émise... (ce n'est pas parce qu'un fichier ZIP a un CRC que tu vas dire que ce n'est pas du binaire). Bon, quand j'ai fait mon premier post j'admets que j'avais pas trop fait gaffe à quel sous-ensemble du trinaire était utilisé (ce n'était pas vraiment ma préoccupation), mais dès que tu me l'as fait remarquer, j'ai effectivement vu qu'on pouvait *bijectivement* faire correspondre la représentation trinaire de mon post de départ à une représentation binaire... Ce qui fait qu'effectivement c'est plus approprié d'appeler ça un signal binaire, évidemment, mais ça n'empêche pas que toutes mes explications sont VRAIES du début à la fin

Voilà mon post de départ édité, puisque tu as l'air d'y tenir :

Pollux :
Codage physique
1200bps binaire.

Encapsulation
Un "trooon" est constitué successivement :
* d'un quasi-silence pour dire de faire attention à la suite
* d'un sinusoïde à 600 Hz pour synchroniser
* des données binaires elles-même
(on peut assimiler le sinusoïde à la suite trinaire PNPNPNPNP...)

Si on convertit tout ça en trinaire, on obtient quelquechose de la forme :

<sync> <start> données

où
<sync> = (10)*0
<start> = 11111001101001000010101110110000

Les signaux se présentent sous l'une des deux formes :

Frames type A
Ils sont de la forme :

<sync> <start> <channel0> <channel1> ... <channel15>

avec <channelX> un mot de 32 bits
Pour une valeur de X donnée, <channelX> ne décrit que peu de valeurs différentes, du moins dans le court extrait qu'il y a.
Dans la plupart des frames, quasiment tous les canaux sont tels que <channelX> = <void>
avec
<void> = 11110101000100111000001100101110

Je ne sais pas à quoi c'est censé correspondre, mais il se pourrait que les canaux correspondent à différents services, et les <channelX> à un état donné du service. C'est très très probable que les <channelX> ne contiennent pas l'équivalent de 32 bits d'information, mais bien moins (code de redondance cyclique par exemple).

En fait, sur toute la durée du signal, il n'y a que 9 valeurs distinctes de <channelX> différentes de <void> ! Ca veut sans doute dire "tout va bien".

Frames type B
Ils sont de la forme :

<sync> <start> <data:val0> <data:val1> ... <data:val3> <start> <data:val4> <data:val5> ... <data:val7>

avec <valX> un mot de 16 bits
et
<data:Z> = <void> <datam> <Z> <datam> <Z> <void>
<datam> = 1111111111100000

C'est probable que les <Z> soient moins redondants que les <channelX>, parce qu'ils sont déjà dupliqués pour vérifier les erreurs ^^
En tout cas c'est encore plus bizarre : il y a 6 frames de ce type, mais tous contiennent exactement les mêmes données <valX>





Bref, il y a vraiment très très peu d'information là-dedans : il y a 8 <valX> différents (128 bits), mais qui n'ont pas changé de tout le signal ; et il n'y a que 9 <channelX> distincts (256 bits), et seulement 5 valeurs de X où à un moment il y a eu un <channelX> != <void>.
Ca veut dire que sur plus d'une minute d'enregistrement, il y a de l'ordre de 384 bits = 48 octets de vraies données... (et probablement moins si on tient compte de la redondance, et du fait que sur un temps plus long il n'y aurait pas 2x plus de données) C'est un peu maigre

Pour en tirer qqch d'intéressant il faudrait faire des enregistrement plus longs, par exemple quelques heures...

alors, pourquoi tu en parles? C'est une preuve que tu n'as rien compris au code.

Tes explications sont quand même fausses parce que tu considères toujours les transitions comme codantes alors que c'est les niveaux.

Oublions ça et passons à la suite. Comment décoder de manière automatique la séquence de bits qui se présentent à nous?

j'avais pensé à une dérivation pour transformer une pente en niveau, mais on peut remarquer après que les transitions avaient la même amplitude.

Ce qui nous permet de construire un décodeur, l'état du bit courant change si l'écart entre deux samples dépasse la moitié de la hauteur.

Au fait, la geule strange des créneaux est dûe à un procédé physique nommé la décharge du condensateur qui a scandé les signaux. La constante de temps de la décharge est d'environ 70 ms.

ok tu parles plus de transitions.


MAIS avant de chercher des champs de données tu ferais mieux d'être sûr du codage physique de ces données.

et surtout, ce qui peut être totalement faux, en tout cas absolument pas vérifié, c'est ton organisation en canaux.

Elle ne se justife que si le signal contrôle un processus continu, or d'après les analyses (douteuses mais bon) de la première page, il s'agirait de signaux de bipeurs, donc des paquets de données, mettant à jour un bipeur chacun. donc pas besoin de coder des flux dans des canaux. surtout que ces données sont émises par intermittence.