Leserveur JS (Join Server) introduit au cours de la spĂ©cification LoRaWAN 1.1 (2017) pour la gestion du roaming est Ă©galement prĂ©sent dans la spĂ©cification LoRaWAN 1.0.4 (2020). Les spĂ©cifications LoRaWAN 1.0.x autorisent le Passive Roaming, la spĂ©cification LoRaWAN 1.1 autorise Ă  la fois le passive roaming et le handover Roaming. Nous avons attaquĂ© le problĂšme du dĂ©codage des images transmises par protocole LRPT de Meteor-M2. Tout comme l’utilisateur d’un browser web qui dĂ©sire afficher une image transmise par HTML avec, pour seul outil, une sonde d’oscilloscope branchĂ©e sur un cĂąble Ethernet, nous devons remonter petit Ă  petit les couches OSI pour passer de la couche matĂ©rielle Ă  la couche applicative. L’étude prĂ©cĂ©dente nous avait permis de retrouver, Ă  partir des mesures de phases, la constellation QPSK et des bits dĂ©convoluĂ©s par algorithme de Viterbi. Nous avions Ă©chouĂ© Ă  trouver le mot de synchronisation des trames dans cette sĂ©quence de bits. Poursuivons donc l’exploration pour aller jusqu’au dĂ©codage des images JPEG, dont on affichera le contenu pour avoir une vue de l’espace. 1. Rotation de la constellation Fig. 1 Constellation QPSK chaque Ă©tat possible de phase encode 2 bits. L’assignation de chaque symbole vers les paires de bits sera l’objet d’une partie du travail de dĂ©codage. Cette figure est issue de [1, Fig. L’absence de corrĂ©lation observĂ©e Ă  l’issue de l’étude prĂ©cĂ©dente indique que nous ne comprenons pas comment les bits sont encodĂ©s dans le message acquis, sous rĂ©serve que le mot de synchronisation encodĂ© par convolution soit correct, hypothĂšse que nous ferons compte tenu des informations fournies sur [2]. Lorsque nous avions Ă©tudiĂ© la modulation en phase binaire BPSK – Binary Phase Shift Keying, nous avions vu que deux cas pouvaient se produire [3][4] soit le signal acquis Ă©tait en phase avec l’oscillateur local, et les bits issus de la comparaison de la phase entre le signal reçu et la reproduction locale de la porteuse boucle de Costas Ă©taient ceux attendus, soit le signal Ă©tait en opposition de phase et les bits Ă©taient inversĂ©s par rapport Ă  la valeur attendue. Dans les deux cas, la corrĂ©lation avec le mot de synchronisation accumule de l’énergie le long de la sĂ©quence de bits et se traduit, en prenant la valeur absolue, par un pic de corrĂ©lation, que nous ayons la bonne sĂ©quence dans la trame acquise ou son opposĂ©. Ce cas simple se complique dans le cas de QPSK Quadrature Phase Shift Keying [5], dans lequel la phase prend quatre Ă©tats possibles qui encodent chacun une paire de bits figure 1. L’assignation entre la valeur de la phase et la paire de bits correspondante n’est pas Ă©vidente, mais surtout toute erreur dans l’assignation symbole-paire de bits se traduit par une sĂ©quence erronĂ©e, qui ne corrĂšle pas avec le mot recherchĂ©. À titre d’exemple, si nous attribuons 0° Ă  la paire de bits 10 et 90° Ă  11 code de Gray, dans lequel seul 1 bit change entre deux valeurs adjacentes de la phase alors une sĂ©quence 0-90° se traduit par 1011, alors que l’assignation 0° Ă  11 et 90° Ă  01 interprĂšte la mĂȘme sĂ©quence de phases par 1101 les deux messages issus de la mĂȘme sĂ©quence de phases mesurĂ©es sont complĂštement diffĂ©rents et n’ont aucune chance d’accumuler l’énergie nĂ©cessaire au pic de corrĂ©lation, lors de la comparaison avec le motif de synchronisation de rĂ©fĂ©rence. On notera, en comparant la figure 1 Ă  la derniĂšre figure de la premiĂšre partie de cet article, que nous avions placĂ© la paire de bits 00 sur la mauvaise valeur de phase voir figure 7 de la section 5 de l’article prĂ©cĂ©dent, pour l’assignation entre chaque symbole et chaque paire de bits dans le Constellation Soft Decoder – -1+1j, 1+1j, 1-1j], [0, 1, 3, 2], 4, 1.base, et l’analyse que nous proposons ici en figure 2. Par ailleurs, le code de Gray peut Ă©voluer dans le sens horaire ou trigonomĂ©trique, induisant encore un risque d’erreur. Il ne semble pas y avoir de façon d’identifier l’assignation phase-paire de bits autre que la force brute, dans laquelle toutes les combinaisons de codes possibles sont testĂ©es, tel que nous l’enseigne le contenu de de dans meteor_decoder 1111110010100010101101100011110110110000000011011001011110010100 0101011011111011110100111001010011011010101001001100000111000010 0000001101011101010010011100001001001111111100100110100001101011 1010100100000100001011000110101100100101010110110011111000111101 1111110001010001011110010011111001110000000011100110101101101000 0101011000001000000111001001011100011010101001110011110100111110 0000001110101110100001101100000110001111111100011001010010010111 1010100111110111111000110110100011100101010110001100001011000001 Ceci donne toutes les combinaisons possibles de paires de bits dans le mot encodĂ© par convolution, et la corrĂ©lation du message acquis se fait avec toutes les dĂ©clinaisons de ce code. Fig. 2 Exemple de signaux synthĂ©tiques permettant d’analyser la configuration du Constellation Soft Decoder par calcdist[-1-1j, -1+1j, 1+1j, 1-1j], [0, 1, 3, 2], 4, 1.base. Nous constatons que l’assignation des symboles aux paires de bits ne correspond pas Ă  la norme figure 1. Cependant, nous avons encore un problĂšme ces inversions de bits se font facilement sur des valeurs binaires du mot de rĂ©fĂ©rence en inversant 1 et 0, mais que faire avec les soft bits qui encodent chaque phase reçue dans le message acquis avec une valeur continue codĂ©e sur 8 bits ? Sommes-nous obligĂ©s de dĂ©cider maintenant de la valeur attribuĂ©e Ă  chaque phase soft→ hard bits, ou pouvons-nous manipuler les valeurs brutes ? Il nous faut interprĂ©ter les Ă©changes de bits comme des opĂ©rations de rotation ou de symĂ©trie de la constellation figure 3. Nous constatons qu’échanger des bits correspond Ă  des opĂ©rations entre partie rĂ©elle et partie imaginaire, soit de rotation, soit de symĂ©trie le long d’un des axes du plan complexe. Ainsi, en manipulant la partie rĂ©elle et imaginaire des donnĂ©es acquises, nous pouvons atteindre le mĂȘme rĂ©sultat que l’échange des bits, mais en conservant les valeurs continues des soft bits et en repoussant l’attribution de chaque bit 0 ou 1 Ă  chaque valeur de phase au dĂ©codage par l’algorithme de Viterbi. Fig. 3 Rotations et symĂ©tries de la constellation, et le rĂ©sultat correspondant sur les axes rĂ©el et imaginaire I et Q des donnĂ©es brutes acquises. L’identification de la correspondance entre les 4 Ă©tats QPSK dans le diagramme de constellation I en abscisse, Q en ordonnĂ©e et les paires de bits correspondantes nĂ©cessite donc une attaque brute, dans laquelle tous les cas possibles sont testĂ©s. La corrĂ©lation des phases des signaux acquis avec les diverses permutations possibles du code d’en-tĂȘte de trame encodĂ© par convolution est illustrĂ©e en figure 4. Une seule condition d’attribution des symboles aux paires de bits fournit une sĂ©quence pĂ©riodique de pics de corrĂ©lation figure 4, bas il s’agit de la bonne correspondance, que nous exploiterons pour la suite du dĂ©codage. Fig. 4 CorrĂ©lation pour les 4 cas possibles de rotation de la constellation QPSK avec le code connu de dĂ©but de trame. Nous constatons que seul le quatriĂšme cas – en bas – fournit des pics pĂ©riodiques de corrĂ©lation reprĂ©sentatifs du dĂ©but de trame. C’est donc cette attribution des 4 symboles de QPSK aux paires de bits correspondants qui est correcte. Cette permutation sera dĂ©sormais appliquĂ©e Ă  tous les couples I/Q du message acquis, car nous savons que nous retrouverons alors la sĂ©quence de bits Ă©mise par le satellite, lors du dĂ©codage par algorithme de Viterbi appliquĂ© aux soft bits rĂ©sultants. Des bits aux phrases mise en Ɠuvre du dĂ©codage par algorithme de Viterbi Nous avons maintenant une sĂ©quence de phases comprises dans l’ensemble [0;π/2;π;3π/2] convenablement organisĂ©e pour devenir une sĂ©quence de bits dans laquelle nous retrouvons le mot de synchronisation, et nous n’avons qu’une unique attribution des divers symboles {00;01;11;10} Ă  chaque phase qui fournit une solution prĂ©sentant cette corrĂ©lation. Il nous reste Ă  dĂ©coder pour retirer l’encodage par convolution, puis appliquer aux bits rĂ©sultants qui Ă©taient donc les bits encodĂ©s par le satellite avant convolution une sĂ©quence de XOR OU exclusif avec un polynĂŽme garantissant de rendre la sĂ©quence aussi alĂ©atoire que possible, pour Ă©viter tout risque de rĂ©pĂ©tition trop long du mĂȘme Ă©tat de bit. Nous avons mentionnĂ© la disponibilitĂ© de libfec, implĂ©mentant efficacement le dĂ©codage des signaux encodĂ©s par code de convolution. Nous Ă©tendons ici l’exemple simple au cas pratique de la trame complĂšte. Notre premiĂšre idĂ©e a consistĂ© Ă  dĂ©coder d’un coup l’ensemble du fichier acquis. De cette façon, nous cachons le problĂšme de l’initialisation et de la fin du dĂ©codage du code de convolution par l’algorithme de Viterbi. Cela fonctionne, puisque nous vĂ©rifions aprĂšs dĂ©codage que, tous les 1024 octets, nous retrouvons le code de synchronisation 0x1ACFFC1D. Nous avons rencontrĂ© un problĂšme d’erreur d’accĂšs Ă  un segment mĂ©moire segmentation fault, en allouant le tableau permettant de charger l’ensemble du fichier. En effet, le fichier contenant les octets en soft bits fait 11,17 MB, donc nous avions allouĂ© un tableau statique, comme le ferait tout bon dĂ©veloppeur sur systĂšme embarquĂ© qui n’a pas accĂšs Ă  l’allocation dynamique de mĂ©moire malloc, gourmande en ressources. Cependant, ce faisant nous plaçons le tableau sur la pile, et GNU/Linux impose par dĂ©faut une pile de 8192 kB, tel que nous le dit ulimit -s 8192. PlutĂŽt qu’imposer une limite de taille de pile plus importante, nous nous autorisons sur notre systĂšme d’exploitation une allocation dynamique de mĂ©moire, pour placer le tableau sur le tas et non sur la pile, libĂ©rant ainsi la contrainte de place mĂ©moire occupĂ©e. 01 include // from libfec/ 02 include // gcc -o demo_libfec -I./libfec ./libfec/ 03 include 04 include // read 05 include 06 define MAXBYTES 11170164/16 // file size /8 bytes-> bits /2 Viterbi 07 08 define VITPOLYA 0x4F 09 define VITPOLYB 0x6D 10 int viterbiPolynomial[2] = {VITPOLYA, VITPOLYB}; 11 12 int mainint argc,char *argv[]{ 13 int i,framebits,fd; 14 unsigned char data[MAXBYTES],*symbols; 15 void *vp; 16 17 symbols=unsigned char*malloc8*2*MAXBYTES+6; // *8 for bytes->bits & *2 Viterbi 18 // rootrugged~ ulimit -a 19 // stack size kbytes, -s 8192 20 // -> static allocation stack of max 8 MB, after requires malloc on the heap 21 fd=open"./ readfd,symbols,MAXBYTES*16; closefd; 22 23 for i=1;i hard bits 05 [dv,e]=viterbi[1 1 1 1 0 0 1 ; 1 0 1 1 0 1 1 ],phrase,0; 06 data=dv14end*8+dv24end*4+dv34end*2+dv44end; Finalement, le lecteur dĂ©sireux de poursuivre son exploration de Meteor-M2 exclusivement par GNU Radio n’est pas en reste les codes correcteurs d’erreur et libfec sont implĂ©mentĂ©s dans gr-satellite de et dĂ©crits en dĂ©tail dans le blog de D. EstĂ©vez sur Sous sa direction lors de divers Ă©changes de courriers Ă©lectroniques, nous avons fini par faire aboutir le dĂ©codage du mot de synchronisation par son bloc de dĂ©convolution par algorithme de Viterbi, selon le schĂ©ma de traitement proposĂ© en figure 5. Partant d’un fichier binaire contenant le mot encodĂ© fca2b63db00d9794, par exemple gĂ©nĂ©rĂ© par echo -e -n "\xfc\xa2\xb6\x3d\xb0\x0d\x97\x94" > nous visons Ă  retrouver le mot de synchronisation 1acffc1d qui dĂ©montrerait notre comprĂ©hension du dĂ©codeur. Attention le point qui nous a bloquĂ©s n’est pas la configuration du dĂ©codeur, qui reprend exactement la notation de libfec, mais le format des donnĂ©es en entrĂ©e. En effet, GNU Radio s’attend, tel que dĂ©crit au dĂ©tour de la page d’aide de fec_decode_ccsds_27_fb bloc GNU Radio Companion Decode CCSDS 27 de gr-fec, Ă  recevoir une entrĂ©e comprise entre -1 et +1 et non 0 Ă  +1 comme nous nous y serions attendus pour une reprĂ©sentation de bits il s’agit ici de soft bits, compris entre expjπ=-1 et expj0=+1et non de hard bits. Nous prenons donc les bits issus de la lecture du fichier contenant le mot encodĂ©, multiplions par 2 donc facteur d’homothĂ©tie inverse de 0,5, valeur Ă  renseigner dans , retranchons 1 et Ă©ventuellement, Ă©changeons les valeurs des bits multiplication par -1 pour atteindre le bon rĂ©sultat et non son opposĂ©. Nous vĂ©rifions sur la sortie graphique de la figure 5 que la lecture du fichier est fonctionnelle, et en observant la sortie de ce flux de traitement par xxd par exemple, nous trouvons $ xxd cut -d -f2 1acf fc1d 1acf fc1d 0334 53c0 1acf fc1d .........4S..... Ceci n’est pas parfait, mais ressemble bien Ă  nos attentes. Nous trouvons bien la sĂ©quence 1acffc1d, mais parfois une sĂ©quence erronĂ©e 033453c0 se glisse, du fait d’une mauvaise initialisation du dĂ©codeur de Viterbi. En effet, Viterbi fait l’hypothĂšse d’une initialisation avec tous les Ă©lĂ©ments du registre Ă  dĂ©calage Ă  0, ce qui n’est pas nĂ©cessairement le cas ici lors d’une lecture rĂ©pĂ©titive du mot encodĂ©. D. EstĂ©vez prĂ©sente sur les diverses dĂ©clinaisons sur la configuration du dĂ©codeur pour respecter les diverses dĂ©clinaisons de la norme du CCSDS. Fig. 5 Flux de traitement dans GNU Radio Companion, exploitant gr-satellite et le bloc gĂ©nĂ©raliste de dĂ©codage du code de convolution par Viterbi, FEC Extended Decoder configurĂ© pour respecter la norme du CCSDS pour dĂ©montrer le dĂ©codage du mot de synchronisation. L’entrĂ©e se gĂ©nĂ©ralisera donc au fichier enregistrĂ© et contenant les soft bits de Meteor-M2. Le mot annotĂ© sur le graphique du bas est l’opposĂ© du mot fourni dans le fichier d’entrĂ©e 0xFCA2B63DB00D9794, issu de l’encodage du code de synchronisation pour que la sortie rĂ©ponde Ă  nos attentes l’inversion de bits est prise en charge par la multiplication par -1, juste avant l’affichage en haut Ă  droite du flux de traitement. Nous prĂ©tendons avoir dĂ©codĂ© les messages venant du satellite, mais sommes nous certains de la validitĂ© de ces bits ? Afin de chercher rapidement une sĂ©quence connue de bits, nous reprenons le cas proposĂ© au dĂ©but de cet article, Ă  savoir rechercher par corrĂ©lation un motif connu. Or il se trouve que, sans rien connaĂźtre Ă  l’encodage des paragraphes qui formera l’objet de la suite de ce texte, la description du protocole a inclus dans son Appendice A une description de la trame de tĂ©lĂ©mĂ©trie, censĂ©e contenir la date Ă  bord du satellite, et cette trame est identifiĂ©e par le code PRS-64 formĂ© de la sĂ©quence "2 24 167 163 146 221 254 191". Sommes-nous capables de trouver cette sĂ©quence d’octets dans les trames dĂ©codĂ©es ? Ayant obtenu des bits que nous supposons avoir stockĂ© dans le tableau dv, nous les concatĂ©nons sous GNU/Octave en quartets, puis en octets tableau data et en trames matrice fin ci-dessous 01 % data est le tableau d'octets issus de Viterbi tel que vu auparavant 02 for k=124 % on analyse les 24 premiers blocs 03 d,k=data1+k-1*2048k*2048; % trames de 2048 quartets 04 dd,k=d12end,k*16+d22end,k; % quartets -> octets 05 fin,k=dd5end,k; % retire l'en-tĂȘte de synchro de chaque paquet 06 fin,k=[bitxorfin1255,k',pn bitxorfin1+255255+255,k',pn ... 07 bitxorfin1+255*2255+255*2,k',pn bitxorfin1+255*3255+255*3,k',pn]; 08 end Nous constatons que nous avons dĂ» appliquer un code pn, qui a Ă©tĂ© conçu pour rendre la sĂ©quence de bits aussi alĂ©atoire que possible et donc distribuer l’information par masquage bijectif XOR. Cette structure alĂ©atoire des trames Ă©vite de longues sĂ©quences de la mĂȘme valeur de bits, rendant la rĂ©cupĂ©ration de l’horloge compliquĂ©e. La sĂ©quence de pn longue de 255 Ă©lĂ©ments est fournie sur et nous nous contentons de l’appliquer Ă  nos octets, regroupĂ©s par paquets de 255 les 4 octets d’en-tĂȘte, qui ne subissent pas cette transformation, ont dĂ©jĂ  Ă©tĂ© retirĂ©s. Finalement, ces trames sont analysĂ©es pour y rechercher l’occurrence de la sĂ©quence magique PRS-64, reprĂ©sentative de la trame de tĂ©lĂ©mĂ©trie. L’obtention de cette sĂ©quence prouve que notre procĂ©dure est cohĂ©rente, car non seulement nous identifions la sĂ©quence d’octets indicatrice de la tĂ©lĂ©mesure – sĂ©quence qui n’a Ă  peu prĂšs aucune chance d’apparaĂźtre par hasard – mais en plus l’analyse de la tĂ©lĂ©mesure fournit un rĂ©sultat cohĂ©rent avec les conditions d’acquisition et le dĂ©codage par meteor_decoder Onboard time 1148 sous la forme date_header=final589589+7,9' % on a trouvĂ© la date dans CADU 9 sur les 24 traitĂ©es date=final589+8589+11,9' ans = 11 48 33 197 Nous avons rĂ©ussi Ă  trouver l’heure qu’il Ă©tait Ă  bord du satellite au moment de la capture de l’image, validant la procĂ©dure d’obtention des octets Ă  partir du flux de donnĂ©es I/Q. Maintenant que nous sommes confiants sur la sĂ©quence de bits, le reste de l’analyse n’est plus que de l’assemblage de trame et du dĂ©codage d’images, une activitĂ© plus classique d’informatique que de traitement du signal. Des phrases aux paragraphes La sĂ©quence de bits respecte la norme dĂ©crite dans les documents techniques, nous avons donc fini notre travail de dĂ©codage. Pas tout Ă  fait... le satellite transmet une image, et nous avons obtenu une date. C’est un peu maigre comme rĂ©sultat. Pouvons-nous aller plus loin ? C’est lĂ  que les couches de la norme OSI apparaissent. Une image est une somme consĂ©quente d’informations, trop grosse pour ĂȘtre contenue dans un unique paquet transmis depuis le satellite. Pire, le satellite envoie au moins 3 bandes spectrales selon que nous soyons le jour ou la nuit, ces bandes changent... c’est quoi le jour ou la nuit au Spitsberg, avec ses 3 mois de jour et 3 mois de nuit complets ?! qui sont interlacĂ©es entre les divers paquets. Nous comprenons mieux pourquoi la norme OSI sĂ©pare les divers niveaux d’abstraction une image est une entitĂ© dĂ©coupĂ©e en couches de couleurs, qui sont elles-mĂȘmes dĂ©coupĂ©es en blocs codage JPEG, qui sont eux-mĂȘmes dĂ©coupĂ©s en paquets qui sont transmis vers le sol, avec toute l’artillerie de correction d’erreurs et de redondance pour maximiser les chances que le rĂ©cepteur reçoive un flux de donnĂ©es intĂšgre. J’ai bien Ă©crit JPEG dans la phrase prĂ©cĂ©dente pour quelqu’un qui a Ă©tĂ© Ă©levĂ© avec tous les mĂ©faits des compressions Ă  perte d’images et des artefacts induits par la compression JPEG, est-il possible que les images transmises par satellites soient codĂ©es ainsi ? Le compromis tient probablement entre le dĂ©bit de donnĂ©es accessible sur une liaison relativement basse frĂ©quence et la masse de donnĂ©es Ă  transmettre pour rĂ©cupĂ©rer une image haute rĂ©solution on prendra Ă©videmment soin, lors du traitement de telles images, de ne pas s’apitoyer sur les artefacts de codage des blocs de 8x8 pixels, qui vont ĂȘtre l’objet de la discussion qui va suivre. Le point, fort peu clair dans la documentation, tient sur la dĂ©finition du Minimum Code Unit MCU nous apprenons que chaque MCU comporte 196 zones adjacentes d’une image, chacune formĂ©e de 14 imagettes de 8x8 pixels. Le point qui ne nous Ă©tait pas apparu clair dans la documentation est que les MCU successifs sont indĂ©pendants les uns des autres. Ainsi, une ligne d’image est formĂ©e de 14 MCU, chacune contenant 14 imagettes de 8x8 pixels 14 x 14 = 196 et 14 x 14 x 8 = 1568 pixels est bien la largeur d’une image issue de Meteor-M2. Donc, notre objectif est de dĂ©coder des imagettes de 8x8 pixels encodĂ©es en JPEG, de les concatĂ©ner, et ce, jusqu’à former une ligne d’une image dans une composante spectrale. La procĂ©dure se rĂ©pĂšte pour les deux autres bandes spectrales, avant de recommencer suite Ă  une trame de maintenance identifiant 70 fourni dans le champ APID, APplication IDentifier – les images ont quant Ă  elles des identifiants APID compris entre 64 et 69 . Par ailleurs, un paquet MCU peut ne pas entrer complĂštement dans la charge utile de la couche protocolaire M-PDU il se peut que la charge utile d’un M-PDU contienne plusieurs MCU successifs par exemple, lorsque les imagettes compressĂ©es en JPEG sont petites, tel que lors de la transmission d’une zone de couleur uniforme ou bien qu’un MCU soit distribuĂ© entre deux M-PDU. Ainsi, l’en-tĂȘte du paquet VCDU contient un pointeur qui nous informe de l’indice auquel le prochain M-PDU dĂ©marre. Avant ce pointeur, nous obtiendrons la fin du paquet M-PDU prĂ©cĂ©dent. Nous avions placĂ© dans la matrice fin les diverses trames successives, dĂ©codĂ©es aprĂšs application de l’algorithme de Viterbi et derandomization nous affichons le contenu des premiĂšres lignes de cette matrice, pour constater la cohĂ©rence d’un certain nombre de motifs – en-tĂȘte des paquets – avant d’atteindre la charge utile, qui sera elle alĂ©atoire. Le document qui nous est apparu le plus limpide pour dĂ©coder les trames est [7]. octave28> fin116, % voir NASA du PDF 64 64 64 64 64 64 64 64 64 64 64 64 64 64 Version 5 5 5 5 5 5 5 5 5 5 5 5 5 5 Type 140 140 140 140 140 140 140 140 140 140 140 140 140 140 \ 163 163 163 163 163 163 163 163 163 163 163 163 163 163 - counter 43 44 45 46 47 48 49 50 51 52 53 54 55 56 / 0 0 0 0 0 0 0 0 0 0 0 0 0 0 sig. field 0 0 0 0 0 0 0 0 0 0 0 0 0 0 VCDU insert 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ... zone 0 0 2 1 0 0 0 0 0 0 0 0 2 0 5 bits 0 18 142 28 54 18 130 78 226 0 20 70 28 82 32 M_PDU header 77 166 239 222 73 82 83 199 8 28 232 247 165 183 M_PDU... 133 188 229 42 24 23 220 94 68 117 92 151 87 203 ... 882 bytes 75 177 221 215 0 48 49 128 13 166 8 218 126 212 42 138 254 87 12 32 249 87 34 172 247 107 9 142 146 238 236 80 215 96 143 121 0 124 12 89 86 191 179 227 64 144 89 59 240 105 105 251 46 43 0 199 ^ Nous analysons ceci comme suit, de la premiĂšre Ă  la derniĂšre ligne, en commençant par le VCDU Primary Header de 6 octets 64 correspond Ă  la version constante de 01, suivie de 6 zĂ©ros pour les bits de poids fort du VCDU Id S/C id. Ainsi, les 8 premiers bits sont 0100 0000 ; suit l’identifiant du satellite qui transmet champ Type de VCDU Id ce champ est renseignĂ© dans [6] comme valant 5, si l’instrument est prĂ©sent et 63, si l’instrument est absent. Ici, une valeur de 5 est un bon prĂ©sage pour la suite du dĂ©codage des images. Par ailleurs, [8, p. 149] indique qu’un VCDU Id de 5 AVHRR LR sera associĂ© aux canaux APID 64..69, que nous identifierons plus tard ; le VCDU Counter de 3 octets s’incrĂ©mente Ă  chaque paquet, tel que nous l’observons avec le dĂ©compte sur le dernier octet 140 163 43..56 du triplet d’octets, correspondant au compteur de trame ; tous les champs suivants signaling field sont renseignĂ©s comme nuls, pour indiquer la transmission de donnĂ©es en temps rĂ©el, tout comme les champs VCDU Insert zone et l’absence de cryptographie [8, p. 150] ; enfin, les deux derniers octets de l’en-tĂȘte fournissent un pointeur, qui nous indique Ă  quel emplacement se trouvera le dĂ©but du premier paquet contenu dans cette trame. Cette information est probablement la plus importante, car un paquet M_PDU a toutes les chances de se partager entre plusieurs trames et donc, savoir oĂč commence le premier paquet M_PDU contenu dans la trame permet de synchroniser le dĂ©but du dĂ©codage d’une nouvelle image. Les 5 premiers bits sont toujours nuls, tandis que les 11 derniers bits donnent l’adresse, dans la trame, du dĂ©but du premier paquet utile. Dans la sĂ©quence proposĂ©e ici, le pointeur se calcule comme x=fin9,*256+fin10,+12 = 30 154 552 322 30 142 90 238 12 32 82 40 606 44 les 882 octets qui suivent sont la charge utile M-PDU, contenant les champs du canal virtuel Virtual channel field. Nous pourrons nous convaincre que la position de l’en-tĂȘte, identifiĂ©e ci-dessus, est correcte par for k=1lengthx;finxk,k,end, qui renvoie 64 64 64 64 65 65 65 65 68 64 64 64 64 65 qui est la liste des identifiants des canaux virtuels que nous analyserons ci-dessous, les diverses longueurs d’onde observĂ©es pour former les images APID compris entre 64 et 69 [6] ; la 9e colonne est un peu spĂ©ciale, car elle contient le premier paquet de la sĂ©quence de transmissions du canal d’APID 68, donc un en-tĂȘte d’offset par rapport Ă  la fin de l’en-tĂȘte du VCDU, qui permet de commencer Ă  apprĂ©hender le format de la charge utile M_PDU, sans avoir Ă  en rechercher le dĂ©but. Nous verrons ainsi que 8=0000 1000 est la version ID=000/Type Indicator=0/Secondary Header 1=present/000 APID, puis APID=68 est un des canaux de mesure et finalement, la longueur du paquet en octets est fournie par {0 105}. 2. Que de texte... des images maintenant Nous avons identifiĂ© comment dĂ©coder la trame VCDU, maintenant il reste Ă  analyser la charge utile qu’est le M_PDU. Plusieurs M_PDU peuvent se regrouper dans une mĂȘme trame VCDU par exemple, lorsque la charge utile qu’est une imagette JPEG est fortement compressĂ©e et un M_PDU peut se distribuer entre deux VCDU successifs – il n’y a aucune raison pour que la taille de la charge utile M_PDU soit multiple de la taille d’une trame VCDU. Nous avons identifiĂ© auparavant les pointeurs, dans l’en-tĂȘte du VCDU, de l’adresse de dĂ©but de chaque paquet M_PDU contenu dans le VCDU. Si nous affichons les premiers octets de chaque M_PDU, nous observons un motif cohĂ©rent 8 8 8 8 8 8 8 8 8 8 8 68 68 68 68 68 68 68 70 64 64 64 13 13 13 13 13 13 13 205 77 13 13 34 35 36 37 38 39 40 41 42 43 44 0 0 0 0 0 0 0 0 0 0 0 105 47 49 69 81 107 57 57 97 77 79 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 2 2 2 2 2 2 2 2 2 2 136 136 136 136 136 136 136 136 136 136 136 181 181 181 181 181 181 181 181 186 186 186 124 124 124 124 124 124 124 124 76 76 76 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 98 112 126 140 154 168 182 2 0 14 28 0 0 0 0 0 0 0 24 0 0 0 0 0 0 0 0 0 0 167 0 0 0 255 255 255 255 255 255 255 163 255 255 255 240 240 240 240 240 240 240 146 240 240 240 77 77 77 77 77 77 77 221 77 79 81 243 186 210 178 136 175 242 154 173 238 235 197 41 160 177 253 120 216 191 166 148 77 60 194 210 146 236 9 151 11 88 100 166 240 156 80 106 84 81 201 48 42 228 208 105 41 5 65 152 245 135 33 131 208 9 254 104 41 23 193 172 56 197 38 210 28 91 52 20 205 1 233 249 0 62 115 118 Nous allons analyser ceci dans le cas particulier de la premiĂšre colonne 68 est l’identifiant packet identifier de l’instrument Ă  bord du satellite qui transmet l’information, APID. Comme une image d’un instrument s’étalera sur plusieurs paquets successifs, il est normal que nous retrouvions plusieurs fois de suite le mĂȘme APID. Un cas intĂ©ressant est l’APID 70 de la colonne 8, qui indique une trame de tĂ©lĂ©mesure qui nous avait permis auparavant de trouver l’heure Ă  bord du satellite, au moment de la prise de vue. “13 34” est formĂ© de deux premiers bits, indiquant s’il s’agit du premier paquet d’une sĂ©quence 01 ou la suite d’une transmission 00, suivie du compteur de paquets, sur 14 bits, qui nous servira Ă  savoir si nous avons perdu une imagette dans une ligne. Nous constatons bien que l’octet de poids faible s’incrĂ©mente Ă  chaque nouveau M_PDU. Les deux octets qui suivent indiquent la longueur du paquet M_PDU, ici 105 octets. Suit la date codĂ©e sur 64 bits, soit un jour sur deux octets “0 0”, un nombre de millisecondes dans la journĂ©e codĂ© sur 32 bits “2 136 181 124”, valable pour tous les paquets d’une mĂȘme image et finalement, un complĂ©ment de date en microsecondes codĂ© sur 16 bits et fixĂ©, pour Meteor-M2, Ă  “0 0”. La description du champ de donnĂ©es indique l’indice du premier MCU Minimum Code Unit, imagette dont l’assemblage formera une ligne de l’image finale. Cet indice de MCU s’incrĂ©mente de 14 entre deux paquets successifs, ici 98 112 126, puisque les imagettes sont regroupĂ©es par paquets de 14, pour amĂ©liorer la compression. Finalement, l’en-tĂȘte de l’image contient 16 bits fixĂ©s Ă  0 Scan Header suivi du Segment Header contenant un indicateur de prĂ©sence de facteur de qualitĂ© sur 16 bits, fixĂ© Ă  0xFF 0xF0 ou 255 240 suivi de la valeur de ce facteur de qualitĂ©, qui interviendra dans la quantification de l’imagette JPEG – dans notre cas 77, mais variable le long d’une ligne de l’image finale. Suivent les donnĂ©es des 14 MCU successifs formant 14 imagettes de 8x8 pixels, ou 64 octets successifs dans la nomenclature dans le cas de la premiĂšre trame, cette charge utile commence par 243 197. Cette description un peu fastidieuse est nĂ©cessaire pour bien comprendre le lien entre les VCDU et les M_PDU, qui finalement reprĂ©sentent deux abstractions du flux de donnĂ©es, Ă  deux niveaux diffĂ©rents des couches OSI. Une fois cette distinction assimilĂ©e, l’assemblage des imagettes JPEG, pour former une ligne, n’est plus que question de rigueur dans le suivi de la norme. Sous GNU/Octave, les octets reprĂ©sentant chaque MCU, composĂ© de 14 imagettes, sont regroupĂ©s dans des fichiers individuels suivant le bout de programme 01 for col=123 % numĂ©ro de colonne = numĂ©ro de frame VCDU 02 first_head=fin9,col*256+fin10,col % 70 pour colonne 11 03 fin[1first_head+1]+9,col';% dĂ©but de la ligne 11 1er header en 70 04 fin[122]+first_head+11,col';% dĂ©but du MCU de la ligne 11 05 06 clear l secondary apid m 07 l=finfirst_head+16-1,col*256+finfirst_head+16,col; % vector of packet lengths 08 secondary=finfirst_head+16-5,col; % initialise la liste des en-tĂȘtes 09 apid=finfirst_head+16-4,col; % initialise la liste des APIDs 10 m=fin[first_head+12first_head+12+P],col; 11 k=1; 12 while suml+k*7+first_head+12+P1 quality=atoiargv[1]; 09 fd=open" 10 len=readfd, packet, 1100; 11 closefd; 12 len, 65,0,0,quality; 13 } Ceci se linke sur et de l’archive GitHub citĂ©e prĂ©cĂ©demment. En exploitant ce programme, Ă  qui nous fournissons en format binaire la charge utile qu’est chaque MCU, nous obtenons en sortie une matrice de 14x64 Ă©lĂ©ments que nous nommerons imag, chaque ligne de 64 octets Ă©tant elle-mĂȘme une imagette de 8x8 pixels. En rĂ©organisant sous GNU/Octave ces 64 Ă©lĂ©ments par m=[];for k=1sizeimag1 a=reshapeimagk,,8,8; m=[m a'];end, nous obtenons une matrice de 112x8 pixels que nous affichons par imagescm pour visualiser l’image, telle que prĂ©sentĂ©e en figure 6 gauche. Cette procĂ©dure est rĂ©pĂ©tĂ©e pour les 14 MCU qui forment une ligne de l’image finale la figure 6 illustre la concatĂ©nation de la premiĂšre sĂ©rie d’imagettes gauche avec une seconde sĂ©rie, dĂ©montrant la continuitĂ© des motifs. Cette sĂ©quence se poursuit pour toute une ligne d’images acquise Ă  une longueur d’onde donnĂ©e par un instrument donnĂ© donc une valeur d’APID donnĂ©e, avant de reprendre pour un nouvel APID et ainsi former, en parallĂšle, plusieurs images acquises Ă  plusieurs longueurs d’onde. On notera l’excellent facteur de compression de JPEG sur ces zones relativement homogĂšnes il ne faut qu’une soixantaine d’octets pour encoder ces images de 14x64=896 pixels. Les zones les plus structurĂ©es nĂ©cessitent tout de mĂȘme des MCU de plusieurs centaines d’octets, voire jusqu’à 700 octets. Fig. 6 DĂ©codage d’un MCU haut formĂ© de 14 imagettes de 8x8 pixels successives, et concatĂ©nation avec le MCU suivant bas pour former une image de 28x8=224 pixels de large et 8 pixels de haut. L’image complĂšte finale sera ainsi assemblĂ©e petit Ă  petit par morceaux de MCU. Cet exemple porte sur l’APID 68. Le rĂ©sultat de l’assemblage des images dĂ©compressĂ©es de JPEG vers des matrices de 8x8 pixels est illustrĂ© en figure 7 pour l’instrument d’APID 68. Nous commençons Ă  entrevoir une sĂ©quence cohĂ©rente d’images, mais clairement il manque quelques vignettes sur chaque ligne, car quelques paquets Ă©taient corrompus et n’ont pas pu donner lieu Ă  un dĂ©codage figure 7. Fig. 7 Haut rĂ©sultat du dĂ©codage des imagettes JPEG et assemblage sans tenir compte du compteur. Nous observons clairement un dĂ©calage du motif lorsque des paquets manquent, rĂ©sultant dans une image Ă  peine exploitable. Bas si le compteur de paquet n’atteint pas la valeur attendue de 14 imagettes/MCU, alors de faux paquets manquants sont insĂ©rĂ©s cette fois, l’image est convenablement alignĂ©e. Ici, l’APID est 68. Nous pallions Ă  ce dysfonctionnement, au moins provisoirement, en dupliquant chaque image manquante comme indiquĂ© par le compteur de MCU Ă  dĂ©faut de retrouver l’information perdue, nous arrivons au moins Ă  aligner selon la verticale de l’image des vignettes adjacentes et ainsi, obtenir une image reconnaissable figure 8. Dans cet exemple, nous n’avons pas utilisĂ© l’indice de qualitĂ©, qui modifie les facteurs de quantification de la compression JPEG en fonction de la nature de l’image, et des discontinuitĂ©s sur les tons de gris restent visibles. Fig. 8 RĂ©sultat du dĂ©codage de l’APID 65, avec exploitation du compteur pour identifier les imagettes manquantes, mais sans exploitation de l’information de qualitĂ© du code JPEG. Les caractĂ©ristiques gĂ©ographiques sont visibles, mais de forts contrastes existent au sein de l’image, la rendant peu esthĂ©tique. En intĂ©grant le facteur de qualitĂ© comme argument passĂ© au dĂ©codeur d’imagettes de meteor_decoder sur lequel nous lions notre programme, les tons de gris s’homogĂ©nĂ©isent pour donner un rĂ©sultat convaincant figure 9, proche de la rĂ©fĂ©rence qu’est l’image entiĂšrement dĂ©codĂ©e par meteor_decoder figure 10. On notera qu’il s’agissait d’un passage du satellite loin de l’optimal lors d’une Ă©coute depuis la France, puisque sont clairement visibles l’Istrie, les Alpes italiennes et autrichiennes ainsi que le lac Balaton en Hongrie structure allongĂ©e Ă  l’abscisse 1050, environ en milieu d’image, laissant penser Ă  un passage s’approchant de l’horizon Est. Fig. 9 RĂ©sultat du dĂ©codage de l’APID 65, avec exploitation du compteur pour identifier les imagettes manquantes, et de l’information de qualitĂ© du code JPEG. Les imagettes individuelles sont maintenant Ă  peine visibles et les tons de gris Ă©voluent continuellement sur l’image. Fig. 10 RĂ©sultat du dĂ©codage de l’APID 65 par medet, servant de rĂ©fĂ©rence pour comparaison avec la figure 9. 3. DĂ©codage des images JPEG Nous avons exploitĂ© gr-starcoder, sans en comprendre le contenu. Cela ne saurait nous satisfaire nous devons comprendre, par quelle magie, des coefficients de Fourier ont Ă©tĂ© convertis en une imagette d’intensitĂ© lumineuse de pixels dans le domaine spatial nous sommes en tons de gris, donc nous oublions le concept de couleur seule l’intensitĂ© lumineuse, ou luminance, importe dans ce traitement. Nous dĂ©sirons comprendre comment, Ă  partir du MCU fourni par le dĂ©codage des trames, retrouver une imagette au format JPEG de 8 par 8 pixels. Nous savons qu’il y a un codage sans pertes de Huffman, avec Ă©ventuellement Ă©limination des redondances en copiant une valeur qui se rĂ©pĂšte RLE – Run Length Encoding, pour finalement convertir les coefficients de Fourier dans le domaine spatial par une transformĂ©e en cosinus discrĂšte. Le principal point de friction tient en la dĂ©finition de la table de Huffman. Tout le monde pourra visiter les multiples pages dĂ©crivant [10, section le calcul de l’arbre binaire, permettant de trouver une reprĂ©sentation des donnĂ©es minimisant le nombre de bits nĂ©cessaires Ă  reprĂ©senter les informations les plus frĂ©quentes, quitte Ă  augmenter le nombre de bits nĂ©cessaires Ă  reprĂ©senter les informations les moins frĂ©quentes statistiquement, le fichier s’en trouvera souvent rĂ©duit en taille c’est pourquoi la compression d’un fichier texte, avec beaucoup de redondance, est trĂšs efficace alors que la compression d’un exĂ©cutable binaire, oĂč tous les octets sont Ă  peu prĂšs Ă©quiprobables, ne donne que des rĂ©sultats mĂ©diocres. Un point qui peut rendre le fichier compressĂ© plus volumineux que le fichier original est le fait de transmettre la table de correspondance entre sĂ©quences de bits et donnĂ©es dĂ©codĂ©es. Dans le cas de LRPT, le choix est fait d’exploiter une table fixe, standardisĂ©e aprĂšs analyse de suffisamment d’images pour avoir une distribution statistiquement reprĂ©sentative du nombre d’apparition de chaque symbole. La norme LRPT nous explique simplement de consulter [9]... un raccourci quelque peu grossier, puisque nous n’avons identifiĂ© qu’une unique page utile, sur les 186 que compte la norme ! Les tables qui permettront de retrouver les arbres de dĂ©codage pour les composantes DC – frĂ©quences nulles – et AC – frĂ©quences non nulles – de la transformĂ©e de Fourier de l’image se trouvent en page 158. Nous allons donc nous efforcer, grĂące aux explications de et section 3, de comprendre comment lire ces tables, nommĂ©es DHT pour Define Huffman Table. On nous explique que le nombre de codes composĂ© de N bits est X’00 02 01 03 03 02 04 03 05 05 04 04 00 00 01 7D’ Et que l’assignation de la valeur Ă  chacun de ces codes suit la sĂ©quence X’01 02 03 00 04 11 05 12 21 31 41 06 13 51 61 07' ... Notez que ces sĂ©quences sont celles visibles dans de meteor_decoder premiĂšres lignes du tableau t_ac_0. La partie implicite est comment former lesdits codes ! La premiĂšre table nous informe qu’il y a 0 code de 1 bit, 2 codes de 2 bits, 1 code de 3 bits, 3 codes de 4 bits, 3 codes de 5 bits, 2 codes de 6 bits... Il nous faut donc former cette sĂ©quence de bits. L’opĂ©ration consiste Ă  compter en binaire, et lorsque nous incrĂ©mentons le nombre de bits nĂ©cessaires Ă  continuer la sĂ©quence, nous partons de la sĂ©quence prĂ©cĂ©dente que nous complĂ©tons d’un 0 en rouge ci-dessous. Cela donne en pratique 00 premier code de deux bits 01 second code de deux bits 10 unique code de 3 bits 101 premier code de 4 bits 1011 deuxiĂšme code de 4 bits 1100 troisiĂšme code de 4 bits 1101 premier code de 5 bits 11011 deuxiĂšme code de 5 bits 11100 troisiĂšme code de 5 bits 11101 premier code de 6 bits 111011 second code de 6 bits 111100 premier code de 7 bits ... Et la table qui suit nous informe de la valeur associĂ©e Ă  chacun de ces codes 00 = 1 01 = 2 100 = 3 1010 = 0 1011 = 4 1100 = 0x11 = 17 11010 = 5 11011 = 0x12 = 18 11100 = 0x21 = 33 111010 = 0x31 = 49 111011 = 0x41 = 65 1111000 = 6 1111001 = 0x13 = 19 ... On se rassurera en constatant que la somme des Ă©lĂ©ments de la premiĂšre table vaut 162, qui est bien le nombre d’élĂ©ments dans la seconde table il y aura donc bien une valeur pour chaque code. Bien que les valeurs soient comprises entre 0 et 255, nous constatons que 125 de ces Ă©lĂ©ments nĂ©cessiteront 16 bits pour ĂȘtre codĂ©s au lieu de 8. NĂ©anmoins, comme la majoritĂ© des valeurs se regroupe autour des quelques Ă©lĂ©ments, ces valeurs codĂ©es sur 16 bits apparaissent suffisamment peu souvent pour qu’en moyenne, la compression soit rentable. Une façon Ă©lĂ©gante, mĂȘme si peu utile, pour se raccrocher aux arbres binaires bien connus du codage de Huffman, est de reprĂ©senter le code tel que proposĂ© sur la figure 11. Fig. 11 ReprĂ©sentation en arbre binaire de la table du code de Huffman, proposĂ© dans [9]. Le problĂšme est le mĂȘme, mais plus simple pour la composante DC qui contient beaucoup moins de valeurs X’00 01 05 01 01 01 01 01 01' Le contenu est ici sĂ©quentiel de 0 Ă  0xb = 11. Ici encore, nous ne constatons aucun code de 1 bit, 1 code de 2 bits, 5 codes de 3 bits, puis 1 code de 4 Ă  9 bits. Cette sĂ©quence s’écrit donc 00 = 0 010 = 1 011 = 2 100 = 3 101 = 4 110 = 5 1110 = 6 11110 = 7 111110 = 8 ... Nous voici maintenant Ă©quipĂ©s pour dĂ©coder une image JPEG. Si nous observons la sĂ©quence binaire du dĂ©but d’un MCU issu des dĂ©codages prĂ©cĂ©dents, nous obtenons $ xxd -b head -2 00000000 11111011 01010011 11000111 11110110 11110000 11101000 .S.... 00000006 10011111 10110011 00011111 10001101 00111110 00100000 ....> Ceci commence par la composante DC de la transformĂ©e en cosinus discrĂšte de l’image, suivi des 63 composantes AC la transformĂ©e de Fourier est bijective, donc les 64 pixels de l’imagette de 8 par 8 pixels donnent 64 coefficients de Fourier, avec Ă©ventuellement un certain nombre de valeurs nulles. À chaque fois, nous aurons le couple “nombre de bits” suivi de “valeur”. En suivant Ă  partir du dĂ©but jusqu’à atteindre le premier code DC valable, nous constatons que nous obtenons 111110 premier 0 atteint, soit la valeur 8 dans la seconde table qui nous venons d’exposer. Cela signifie que la valeur de la composante DC est codĂ©e sur les 8 bits qui suivent, soit 11 010100=212 en dĂ©cimal. Nous verrons plus bas si cette valeur est correcte. Suit le premier des 63 coefficients AC ici encore, nous lisons la sĂ©quence de bits jusqu’à atteindre le premier code valable dans la premiĂšre table exposĂ©e ci-dessus 11 11000 est le premier code valable que nous rencontrons, qui est associĂ© Ă  la valeur 6. Le premier coefficient AC est donc codĂ© par les 6 bits qui suivent, soit 111 111=63 en dĂ©cimal. Continuons pour dĂ©couvrir une autre subtilitĂ© de l’assignation des codes aux sĂ©quences de bits nous poursuivons oĂč nous nous Ă©tions arrĂȘtĂ©s dans la lecture des bits pour trouver 1011, qui correspond Ă  la valeur 4 et indique que nous lisons les 4 bits qui suivent, soit 0 111 pour connaĂźtre la valeur du coefficient suivant. Et lĂ , une simple conversion binaire ne convient plus, puisque la reprĂ©sentation n’est pas en complĂ©ment Ă  2, mais sĂ©quentielle, avec le codage du nombre signĂ© composĂ© uniquement de 0s, reprĂ©sentant la valeur minimum de l’intervalle et le codage formĂ© de 1s, la valeur maximale. Donc 0 111 ne vaut pas +7 comme le ferait un bĂȘte convertisseur binaire vers dĂ©cimal, mais -8 puisque sur 4 bits, nous pouvons reprĂ©senter de -15 Ă  +15 en excluant l’intervalle de -7 Ă  +7, qui aurait Ă©tĂ© codĂ© avec moins de bits. Ceci est rĂ©sumĂ© dans le tableau F1 de la page 89 de [9] ou Table 5 de que nous reproduisons ici dans le tableau suivant, montrant la correspondance entre le nombre de bits affectĂ©s Ă  une valeur, la sĂ©quence de bits et la valeur elle-mĂȘme on notera que l’intervalle pris en charge par un nombre infĂ©rieur de bits est exclu de l’intervalle reprĂ©sentĂ© par un nombre de bits donnĂ© Longueur 0 0 1 0 1 -1 1 2 00,01 10,11 -3, -2 2,3 3 000,001,010,011 100,101,110,111 -7,-6, 4,5,6,7 4 0000,...,01111 1000,...,1111 -15,...,-8 8,...,15 5 00000,...,011111 10000,...,11111 -31,...,-16 16,...,31 6 000000,... ...,111111 -63,...,-32 32,...,64 7 0000000,... ...,1111111 -127,...,-32 32,...,64 8 00000000,... ...,11111111 -255,...,-128 128,...,255 ... ... ... ... ... Suit ensuite le code 100 qui vaut 3 et dont les 3 bits qui suivent valent 00 1 soit -6, et nous continuons ainsi pour dĂ©coder tous les coefficients de Fourier ou rencontrer la valeur 0 pour le nombre de bits, signifiant la fin du MCU avec tous les autres coefficients nuls. Une fois les coefficients obtenus, ils sont rĂ©organisĂ©s selon le motif de zigzag dĂ©crit en figure 5 de [9] ou explicitĂ© avec l’indice de chaque case de la matrice en figure 12, et la transformĂ©e en cosinus discrĂšte est effectuĂ©e, pour passer du domaine spectral au domaine spatial. Fig. 12 Assignation de la position de chaque coefficient dans le codage en zigzag des coefficients, maximisant d’avoir les coefficients importants en dĂ©but de sĂ©quence et d’éliminer bon nombre de coefficients de frĂ©quence Ă©levĂ©e vers la droite et le bas lors de la quantification. Nous pouvons nous convaincre de la validitĂ© de l’analyse, en modifiant lĂ©gĂšrement de pour afficher les coefficients avant rĂ©organisation et transformĂ©e en cosinus nous affichons le contenu nombres Ă  virgule flottante ! de zdct[], juste avant la boucle dct[i] = zdct[ZIGZAG[i]] * dqt[i]; qui rĂ©organise les coefficients selon le motif de zigzag. Ce faisant, nous obtenons 212 63 -8 -6 -27 -156 52 65 -2 10 3 -1 21 -1 -4 6 -14 0 6 2 4 1 0 2 4 5 0 16 1 -12 3 -1 0 -3 0 17 3 -2 1 0 2 7 -8 -4 3 -1 -1 1 -5 -1 0 -1 1 5 1 -1 -2 1 -1 -1 -1 1 1 0 Ceci commence bien par la sĂ©quence que nous avons identifiĂ©e pour se poursuivre avec les 64 coefficients. AprĂšs rĂ©organisation selon le motif de zigzags et application du facteur d’homothĂ©tie qui a permis d’annuler un certain nombre de coefficients lors de la compression, nous obtenons un vecteur que nous nommerons coefficients 1484 315 -780 364 -44 108 368 28 -48 -162 390 -9 -168 0 -336 -200 -36 -12 147 0 90 78 224 -104 60 -8 60 52 -23 80 111 145 24 20 34 0 0 -50 47 35 44 0 -75 29 -37 -48 -52 -42 23 0 -72 40 0 -112 -55 46 561 126 -220 -45 52 -46 47 0 Ce sont les 64 coefficients dans le domaine spectral sur lesquels s’applique la transformĂ©e en cosinus discrĂšte fonction idct2 de la signal processing toolbox de GNU/Octave – page 27 de [9] avec C = 1 / √2 et Ck≠ = 1 et S la matrice des coefficients de Fourier. AprĂšs l’iDCT, le dĂ©codeur fournit la sĂ©quence de 64 valeurs, que nous nommerons image 410 299 332 320 292 508 307 222 304 189 185 283 95 353 290 160 252 474 370 552 558 497 273 109 149 261 215 264 328 340 226 -4 417 289 641 512 644 510 245 95 282 56 407 255 466 390 160 -33 418 131 613 569 551 572 96 59 371 47 498 416 460 478 -45 78 Nous la rĂ©organisons en imagette de 8x8 pixels et vĂ©rifions qu’à la constante de 128 prĂšs ajoutĂ©e par gr-starcoder tel que prĂ©conisĂ© par la norme, nous obtenons le mĂȘme rĂ©sultat entreidct2reshapecoefficients,8,8 et reshapeimage,8,8 figure 13. Fig. 13 Une fois la sĂ©quence de coefficients de Fourier obtenue, la fin du traitement est triviale rĂ©organisation le long du motif en zigzag, application du facteur d’homothĂ©tie dĂ©finissant la qualitĂ© de l’image, puis finalement transformĂ©e en cosinus discrĂšte inverse. Partant des coefficients de Fourier en bas Ă  droite, en vĂ©rifiant que la composante continue du signal est bien en coordonnĂ©es 1,1 en haut Ă  gauche de la matrice, nous comparons en haut Ă  droite le calcul effectuĂ© par gr-starcoder et celui obtenu par transformĂ©e en cosinus discret 2D inverse idct2 de GNU/Octave. Nous constatons que l’erreur est Ă  peu prĂšs constante et Ă©gale Ă  128 – constante ajoutĂ©e par gr-starcoder, aprĂšs calcul de l’iDCT en haut Ă  droite. Le facteur d’homothĂ©tie de chaque coefficient, qui est la source par quantification de la perte dans l’algorithme de compression JPEG, s’est dĂ©duit comme suit. Partant de la table de quantification HTK des coefficients de Fourier fournie en Table page 143 de [9] figure 14, un facteur de qualitĂ© Q est fourni avec chaque MCU pour indiquer le facteur de compression de l’image. De ce facteur de qualitĂ© Q, nous dĂ©duisons F=5000/Q si 20
16outils pour vĂ©rifier l’utilisation CPU, disque, mĂ©moire et rĂ©seau sur Linux top. Top est un utilitaire fournit dans la plupart des distributions Linux. Il se prĂ©sente sous la forme d’une vue dynamique et en temps rĂ©el des informations du systĂšme d’exploitation. Le programme fournit une interface interactive limitĂ©e pour la manipulation de processus ainsi qu’une
Recommended Posts Share Existe t il un compteur capable d'enregistrer et de totaliser le trafic d'octets sur le net entrant et sortant, que l'on peut visualiser en premier plan sur le bureau Merci Link to comment Share on other sites Share bonjour... oui ca existe, regarde dans les netgraph ou chose du genre voila ++ Link to comment Share on other sites Author Share bonjour...oui ca existe, regarde dans les netgraph ou chose du genre voila ++ merci mais je trouve ca ou?? Link to comment Share on other sites Share Link to comment Share on other sites Share Link to comment Share on other sites Author Share Merqui ! c'est ce que je cherchais Link to comment Share on other sites Archived This topic is now archived and is closed to further replies. 23- Communications SMS et MMS (Ă©mises depuis la France MĂ©tropolitaine) SMS national: 0,006 € HT / sms: MMS national: 0,065 € HT / mms : SMS internationaux: 0,19 / SMS: MMS internationaux: 0,99 / MMS: La rĂ©ception de SMS en roaming est gratuite. Seuls les SMS Ă©mis sont facturĂ©s. 2.4 – SMS surtaxĂ©s. Les SMS surtaxĂ©s, vers les services SMS+, sont facturĂ©s au Ayumi Bonjour, Merci par avance de l'aide que vous pourrez m'apporter. Je dispose d'un ordinateur Acer Aspire 3000, sous Windows XP. Ainsi que d'une carte wifi D-Link DWL-G630. si il le faut j'apporterai plus d'informations VoilĂ  mon problĂšme Dans mon appartement je dispose d'une connexion Wifi wifirst, je me connecte donc via ma carte wifi d'ordinateur D-Link Ă  la borne internet. Jusqu'Ă  jeudi dernier, tout fonctionnait parfaitement bien, trĂšs bon dĂ©bit et aucune dĂ©connexion. Cependant depuis jeudi soir, il m'est impossible de naviguer sur internet, car je ne reçoit pas assez d'octets pour pouvoir naviguer sur internet. Ma carte wifi fonctionne parfaitement bien Ă  l'universitĂ© et le nombre d'octets reçus et envoyĂ©s sont largement suffisant environ 10 000 paquets reçu. Mais lorsque j'essaye de me connecter sur la borne de wifi de l'appartement, je n'en reçois que 2 ou une dizaine seulement. Et Ă©tant donner la force du signal venant de la borne wifi et la capacitĂ© des autres rĂ©sidents Ă  se connecter au wifi, je suppose que le problĂšme vient de ma carte wifi par rapport Ă  cette connexion. Le problĂšme se caractĂ©rise donc par un nombre de paquets d'octets envoyĂ©s et reçus insuffisants. Donc je reçois la connexion, le dĂ©bit est fort, mais ma carte wifi reçoit peu de paquets. D'oĂč vient le problĂšme ? Pensez vous que cela vient de ma carte wifi, ou de la borne wifi du fournisseur? Que faire lorsqu'on ne reçoit pas assez d'octets ? Merci infiniment par avance pour votre aide.

Etles dĂ©tracteurs du compteur craignent que le champ d’ ondes Ă©lectromagnĂ©tiques Ă©mis par Linky prĂ©sente un risque pour la santĂ©. De nombreuses associations anti-ondes se

Le protocole TCP/IP, adressage IP et routage TCP/IP est actuellement le protocole de communication le plus utilisĂ© dans les rĂ©seaux locaux. C’est aussi le protocole de transport utilisĂ© par le rĂ©seau Internet I/ L’adresse IP A/ Qu’est ce qu’une adresse IP Chaque machine d’un rĂ©seau TCP/IP possĂšde une adresse IP Internet Protocol. Une adresse IP est constituĂ©e d’un groupe de 4 octets soit 4 fois 8 bits, les octets les plus Ă  gauche dĂ©terminent l’adresse du rĂ©seau et le ou les octets de droite dĂ©terminent l’adresse de la machine. correspond Ă  l’adresse rĂ©seau alors que 5 reprĂ©sente l’adresse de l’ordinateur dans le rĂ©seau. Le nombre de machines maximum pouvant ĂȘtre connectĂ©s sur ce type de rĂ©seau est de 254 i1 comporte 256 possibilitĂ©s de 0 Ă  255 mais les octets 0 et 255 sont rĂ©servĂ©s. B/ Les classes d’adresse Les adresses IP sont regroupĂ©es en 3 classes principales. Ce sont les bits de poids forts bits Ă  gauche de l’adresse IP qui dĂ©terminent la classe d’adresse Conclusion pour connaĂźtre la classe d’un rĂ©seau, il suffit de lire le premier est l’adresse IP d’une machine appartenant Ă  un rĂ©seau de classe C 192 appartient Ă  la classe C Remarque l’adresse est une adresse de bouclage ». Cette adresse correspond Ă  l’adresse interne de tout ordinateur et est destinĂ©e Ă  effectuer des tests. Exemple pour tester un serveur web depuis la machine oĂč ce service tourne » il suffit de saisir l’adresse C/ Le masque de sous-rĂ©seau Le masque de sous-rĂ©seau permet de diffĂ©rencier l’adresse IP du rĂ©seau de l’adresse IP de la machine. Comme l’adresse IP, le masque de sous-rĂ©seau se compose d’un groupe de 4 octets. Chaque classe d’adresse comporte un masque par dĂ©faut qui peut ĂȘtre personnalisĂ© pour crĂ©er des sous-rĂ©seaux mais c’est une affaire de spĂ©cialiste. Masques de sous-rĂ©seau par dĂ©faut Les octets ayant la valeur 0 dĂ©terminent la plage d’adresses utilisable pour les machinesExemple Adresse IP 172. Masque de sous-rĂ©seau 0. 0 On en dĂ©duit que cette machine est dans un rĂ©seau de classe B 172 est compris entre 127 et 191 que l’adresse du rĂ©seau est l’adresse de rĂ©seau est codĂ©e sur les 2 premiers octets car les deux premiers octets du masque de rĂ©seau sont Ă©gaux Ă  255 les deux derniers octets servent Ă  identifier de maniĂšre unique chaque machine du rĂ©seau car les deux derniers octets du masque de rĂ©seau sont Ă©gaux Ă  0 que l’adresse IP de la machine est En fait, sur le rĂ©seau on peut avoir potentiellement 65534 machines connectĂ©es. Si on ajoute d’autres machines sur ce rĂ©seau, leur adresse IP commencera alors par et les deux derniers octets seront librement choisis de Ă  D/ Le choix d’une adresse IP Le choix de l’adresse IP n’est pas libre 1 En cas d’ajout d’un nouvel ordinateur Ă  un rĂ©seau local, il faut tenir compte de l’adresse rĂ©seau et vĂ©rifier que l’adresse IP n’est pas dĂ©jĂ  prise par un autre ordinateur 2 La majoritĂ© des adresses IP sont rĂ©servĂ©es pour l’Internet et pour en bĂ©nĂ©ficier il faut les acquĂ©rir auprĂšs de l’Internic. En effet Internet utilise l’adressage IP pour identifier de maniĂšre unique les postes qui lui sont reliĂ©s. Cependant, l’Internic a rĂ©servĂ© trois plages d’adresses IP utilisables dans le cadre d’un rĂ©seau local et inaccessible depuis l’internet. Ces plages d’adresses rĂ©servĂ©es dites publiques » ou adresses non routables ne seront jamais visibles depuis Internet. Ceci permet notamment de limiter les risques d’attaques extĂ©rieures en Ă©vitant que toutes les machines du rĂ©seau soient visibles depuis Internet. Ces plages d’adresses sont Classe A Classe B de Ă  Classe C de Ă  Remarque en raison de la saturation du nombre d’adresses IP sur Internet, une nouvelle norme d’adresses IP norme IPv6 a Ă©tĂ© dĂ©finie et est utilisĂ©e pour les routeurs de l’Internet E/ Adressage IP statique – adressage IP dynamiqueL’adressage IP statique consiste Ă  attribuer Ă  chaque ordinateur serveur, station,
 une adresse IP fixe. Sous Windows 2000, effectuez un clic droit sur l’icĂŽne Favoris rĂ©seau puis cliquez sur PropriĂ©tĂ©s L’adressage dynamique consiste Ă  obtenir une adresse IP automatiquement au moment de la connexion au rĂ©seau, la station client effectue une requĂȘte auprĂšs d’un serveur DHCP DHCP= Dynamic Host Control Protocol pour obtenir une adresse IP. II/ Le routage Le routage permet l’échange de donnĂ©es entre deux ordinateurs qui ne sont pas situĂ©s sur le mĂȘme rĂ©seau. Le routage fait appel Ă  un dispositif physique le routeur. A/ Le routage, comment ça marche ? Sur ce schĂ©ma, il y a trois rĂ©seaux. Supposons que l’ordinateur P2 souhaite contacter l’ordinateur envoie donc un message qui sera rĂ©ceptionnĂ© par tous les postes de son rĂ©seau message de diffusion Si P6 Ă©tait dans le mĂȘme rĂ©seau que P1, P6 aurait reçu directement le message on parle de remise directeLe routeur R4 reçoit le message, il consulte sa table de routage et constate qu’il n’est pas concernĂ© Le routeur R1 reçoit Ă©galement le message, et consulte sa table de routage P6 ip est bien une machine faisant partie du rĂ©seau il peut alors relayer le message et l’adresser Ă  P6. Le routeur agit comme une passerelle entre deux rĂ©seaux. Lorsqu’un message Ă©mis par une machine d’un rĂ©seau concerne un autre rĂ©seau, le routeur redirige alors le message vers le ou les routeurs voisins Pour chaque routeur, on peut alors construire une table de routage Table de routage de R5 A retenir Toute machine d’un rĂ©seau local utilisant TCP/IP est identifiĂ©e par une adresse IP composĂ©e de 4 octets. Un masque de sous-rĂ©seau composĂ© Ă©galement de 4 octets permet de dĂ©terminer d’une part l’adresse de rĂ©seau ou de sous-rĂ©seau et l’adresse de la machine d’autre part. Les adresses IP se rĂ©partissent principalement en 3 classes d’adresses, chaque classe comportant un masque de sous-rĂ©seau par dĂ©faut imageLe routeur comporte trois fonctions principales 1 Permettre la communication entre des machines n’appartenant pas au mĂȘme rĂ©seau 2 Offrir un accĂšs internet Ă  des utilisateurs d’ordinateur en rĂ©seau local 3 Il comporte gĂ©nĂ©ralement un systĂšme de filtrage des paquets IP qui bloque les accĂšs non autorisĂ©s Ă  un rĂ©seau, ce systĂšme s’appelle un pare-feu firewall De plus, bien que les tables de routage puissent ĂȘtre configurĂ©es manuellement dans les petits rĂ©seaux, des protocoles spĂ©cifiques ex RIP = Routing Information Protocol permettent aux routeurs de communiquer entre eux pour Ă©changer dynamiquement de maniĂšre automatique des informations de routage.

uncadran ou l’affichage numĂ©rique d’un nombre sur un compteur (par exemple: un voltmĂštre, un ampĂšremĂštre, un wattmĂštre ou un multimĂštre). L’étude des variations d’une grandeur en fonction d’une autre nĂ©cessite un relevĂ© trĂšs rapide d’une sĂ©rie de points pour obtenir le tracĂ© d’une courbe (par exemple: tracĂ© de l’évolution du courant en fonction du temps ou encore

fabrice88 WRInaute occasionnel Inscrit 15 Octobre 2007 Messages 316 J'aime reçus 0 Bonjour, en parralele avec mon autre message sur ce forum je voudrait savoir comment faire pour comptĂ© le nombre de fois ou un sujet de mon forum aura Ă©tĂ© vue apr les internautes ? J'imaginai faire comme ceci dans ma table forum_sujet, je rajoute un nouveau champ que je nomme 'vues'. ensuite lorsq'un internaute clique sur un sujet pour voir son detail je crĂ© un compteur qui ajoute +1 a chaque ouverture du sujet. Est ce que l'idĂ©e est bonne ou est ce qu'il faut procĂ©der autrement ? Ton idĂ©e est bonne... personnellement je ne vois pas comment tu pourrais faire autrement. ZelkiN WRInaute occasionnel Inscrit 27 Juillet 2007 Messages 458 J'aime reçus 0 En effet tu n'as guerre le choix, et puis la plupart des compteurs sont fait ainsi, aprĂšs tu peux gĂ©rer au niveau des ip pour ne pas compter plusieurs fois la meme page vu au meme utilisateur fabrice88 WRInaute occasionnel Inscrit 15 Octobre 2007 Messages 316 J'aime reçus 0 ok merci bon alors voilĂ  se que je fais //crĂ©ation de la requĂȘte SQL $sqlvue = "UPDATE forum_sujets SET vue = $vue+1 WHERE id = ".$_GET['id_sujet_a_lire']; $reqvue = mysql_query$sqlvue; lors de la toute premiere ouverture de la page j'ai bien l'incrementation du + 1 qui se fait et j'ai donc mon champ vue qui prend la valeur de 1 au lieu de 0. par contre apres sa ne fonctionne plus. si je retourne sur la meme page mon champ vue n'est plus incrĂ©mentĂ© il reste Ă  1. ? Inscrit 14 Mai 2003 Messages 9 171 J'aime reçus 346 C'est le "$vue" qui semble bizarre, je sais pas ce qu'il contient, ça devrait plutĂŽt ĂȘtre //crĂ©ation de la requĂȘte SQL $sqlvue = "UPDATE forum_sujets SET vue = vue+1 WHERE id = ".$_GET['id_sujet_a_lire']; $reqvue = mysql_query$sqlvue; fabrice88 WRInaute occasionnel Inscrit 15 Octobre 2007 Messages 316 J'aime reçus 0 ah oui zut ! Merci. Sa fonctionne. ZelkiN WRInaute occasionnel Inscrit 27 Juillet 2007 Messages 458 J'aime reçus 0 Euh Spout a raison d'une part, d'autre part attention a la sĂ©curitĂ© , ne met jamais un GET pas traitĂ© dans une requĂȘte SQL ! Si il s'agit d'un nombre, vĂ©rifie le avec un is_numeric, ou au moins met un addslashes$_GET['..'] sinon tu risques d'avoir des problĂšmes Bon courage ! Inscrit 14 Mai 2003 Messages 9 171 J'aime reçus 346 Pour Ă©viter les comptages multiples il y a un moyen simple mais pas infaillible - Quand un comptage est fait, envoyer un cookie vers le navigateur du visiteur. - Sauvegarder la derniĂšre IP qui a incrĂ©mentĂ© le compteur. - Avant chaque incrĂ©mentation du compteur, vĂ©rifier si cookie et si pas la mĂȘme IP. Si un petit malin supprime les cookies, il est encore bloquĂ© par la derniĂšre IP. La faille c'est si le visiteur change d'IP et supprime ses cookies, mais c'est quand mĂȘme beaucoup mieux que sans vĂ©rification. Edit oui j'ai pas fait gaffe, il faut Ă©videment bien vĂ©rifier le contenu du _GET avant de le transmettre Ă  la requĂȘte. Avec mysql_real_escape_string au lieu de addslashes fabrice88 WRInaute occasionnel Inscrit 15 Octobre 2007 Messages 316 J'aime reçus 0 quel genre de probleme peut on avoir ? Inscrit 14 Mai 2003 Messages 9 171 J'aime reçus 346 fabrice88 WRInaute occasionnel Inscrit 15 Octobre 2007 Messages 316 J'aime reçus 0 ok donc si je met en tout debut de ma page $id_sujet_a_lire = mysql_real_escape_string$_GET['id_sujet_a_lire']; C'est ok ? Inscrit 14 Mai 2003 Messages 9 171 J'aime reçus 346 fabrice88 WRInaute occasionnel Inscrit 15 Octobre 2007 Messages 316 J'aime reçus 0 ok merci. alors du coup dĂšs que j'intĂ©gre des donnĂ©es dans ma base sql je doit mettre mysql_real_escape_string. Est ce que dans le cas de la requete ci dessous je doit la modifiĂ© $sql = 'INSERT INTO forum_reponses VALUES"", "'.$_POST['auteur'].'", "'.$_POST['message'].'", "'.$date.'", "'.$_GET['numero_du_sujet'].'"'; pour mais sa va ĂȘtre long si y'a beaucoup de champs a remplir... $auteur = mysql_real_escape_string$_POST['auteur']; $message= mysql_real_escape_string$_POST['message']; $date = mysql_real_escape_string$_POST['date']; $numero_du_sujet = mysql_real_escape_string$_GET['numero_du_sujet']; $sql = 'INSERT INTO forum_reponses VALUES"", "'.$auteur.'", "'.$message.'", "'.$date.'", "'.$numero_du_sujet.'"'; Inscrit 23 FĂ©vrier 2004 Messages 13 857 J'aime reçus 5 NB tu as pensĂ© que chaque crawl de GoogleBot, Mediapartners, Slurp! et ses amis va faire une comptabilisation de plus ? roll Inscrit 23 Janvier 2005 Messages 570 J'aime reçus 0 Et si tu as de nombreuses pages vues par jours, ca va te faire un sacrĂ© nombre de requĂȘtes SQL ! fabrice88 WRInaute occasionnel Inscrit 15 Octobre 2007 Messages 316 J'aime reçus 0 Comprend pas... Ah oui ok j'ai compris. Eh bien comment faire pour ne pas les comptabiliser ? Inscrit 1 Mars 2005 Messages 9 119 J'aime reçus 1 Il te faut t'ecrire une petite routine pour les detecter et ne pas les compter ou les compter dans un compteur sĂ©parĂ©. Inscrit 1 Mars 2005 Messages 9 119 J'aime reçus 1 Une solution que j'ai testĂ© a grande echelle stocker les infos dans des fichiers .txt pas de problemes d'accĂšs concurrents donc les .txt vont tres bien et c'est autant de charge en moins pour la base mysql. En plus en optimisant bien le truc tu peux faire une routine ultra rapide qui va acĂ©der en accĂšs direct au 4 ou 5 octets qui te servent au comptage pour chaque page, mĂȘme si tu suis pages web ... et ca sera dans tous les cas moins gourmand que mysql Ă  mon avis. Note et si vraiment tu veux optimiser a donf, tu compte en utilisant les 8 bits et donc 2 octets suffisent par page merci jcaron pour son aide sur les bits .... dans un autre topic. Similar Threads - Compter nombre fois Forum Date Compter le nombre d'occurrences d'un mot dans un site Google l'entreprise, les sites web, les services 30 Juillet 2014 COmpter nombre de clic vs visite Google Analytics 9 Septembre 2013 Script pour compter et afficher le nombre de mots d'une page DĂ©veloppement d'un site Web ou d'une appli mobile 5 FĂ©vrier 2013 Compter le nombre de liens vers une mĂȘme page Administration d'un site Web 17 Octobre 2011 [PHP/MySQL] Compter le nombre de checkbox cochĂ©es DĂ©veloppement d'un site Web ou d'une appli mobile 11 Septembre 2010 Compter le nombre de clients Ă  l'aide de Google Analytics Google Analytics 27 Octobre 2009 Compter le nombre de mots dans une chaine de caractĂšres DĂ©veloppement d'un site Web ou d'une appli mobile 19 Mai 2009 [PHP] compter le nombre de requĂȘtes MySQL DĂ©veloppement d'un site Web ou d'une appli mobile 4 DĂ©cembre 2008 Compter le nombre de caractĂšres d'une chaine DĂ©veloppement d'un site Web ou d'une appli mobile 12 Juillet 2006 Compter le nombre de caractĂšre que retourne un fichier .php DĂ©veloppement d'un site Web ou d'une appli mobile 5 FĂ©vrier 2006 Compter le nombre d'enregistrement diffĂ©rents dans mysql DĂ©veloppement d'un site Web ou d'une appli mobile 31 Janvier 2006 Compter le nombre de caractĂšre dans une chaine ? oui mais... DĂ©veloppement d'un site Web ou d'une appli mobile 9 DĂ©cembre 2005 Comment compter le nombre de / dans l'url ? DĂ©veloppement d'un site Web ou d'une appli mobile 6 Novembre 2005 Comment compter le nombre de pages indexĂ©es d'un site ? RĂ©fĂ©rencement Google 4 Octobre 2004 mĂ©canique - machine Ă  compter les champignons Demandes d'avis et de conseils sur vos sites 28 Janvier 2020 RGPD et consĂ©quences des titres Ă©mis Ă  compter de 2020 Droit du web juridique, fiscalitĂ©... 8 Janvier 2020 Compter les clics sur liens sortants avec redirection Google Analytics 9 Mai 2019 Comment compter les lettres d'un texte ? DĂ©veloppement d'un site Web ou d'une appli mobile 27 AoĂ»t 2016 [ Vos avis compteront tous Demandes d'avis et de conseils sur vos sites 13 DĂ©cembre 2012 Compter les affichages de banniĂšres sous GA pour avoir le taux de clic Google Analytics 10 Septembre 2012
Cetteapplication vous permet de vérifier votre consommation internet en terme d'octets émis et d'octets reçus . Date de Compteur Internet Super facile, Gratuit et sans pub . Date de sortie
Question en attente de rĂ©ponse Attention Ces Ă©changes datent de plus d'un an, leur contenu risque de ne plus ĂȘtre d'actualitĂ©. sommes le 7 mai, et mon compteur indique toujours "aucune consommation" d'internet et ce, depuis le 1er mai, date de changement de mois de faire en sorte que ce compteur soit alimentĂ© chaque jour afin que je puisse suivre ma consommation en temps d' cordialementjlv RĂ©ponses Bonjour Jean-LoĂŻc,Pourriez-vous m'indiquer si vous avez effectuĂ© des connexions aux donnĂ©es mobiles depuis le 1er mai ? Si oui, pourriez-vous m'indiquer si le suivi conso disponible en appelant le 998 appel gratuit fait apparaĂźtre votre consommation internet ?Je reste Ă  votre disposition,LĂ©o de l'Équipe Prixtel Bonjour LĂ©o de l'Ă©quipe Prixtel...Ah, enfin une rĂ©ponse Ă  ma question du 7 mai !Oui, j'ai effectuĂ© des connections internet depuis le 1er mai Ă  titre indicatif, ma consommation moyenne mensuelle internet est de 3,5 Go sur les 12 derniers mois.Et le suivi conso du 998 m'indique une conso Ă  0 profite du prĂ©sent message pour ajouter que je ne parviens plus Ă  ouvrir mon espace client un problĂšme de plus ?Restez bien Ă  ma disposition.... comme vous l'Ă©crivez.... si possible avec efficacitĂ©...Bien cordialementJean-LoĂŻc V. Bonjour Jean-LoĂŻc,Merci de votre retour,Veuillez nous excuser pour ce dĂ©sagrĂ©ment. Nous avons bien pris en compte votre demande et celle-ci a Ă©tĂ© transmise au service concernĂ©. Je reviens vers vous dans les plus brefs ailleurs, si vous ne parvenez pas Ă  vous connecter Ă  votre Espace Client, n'hĂ©sitez pas Ă  vider le cache et les cookies de votre navigateur de l'Équipe Prixtel Jean-LoĂŻc,Suite au retour du service concernĂ©, il apparaĂźt que nous n'avons pas relevĂ© de connexions aux donnĂ©es mobiles Ă©mises depuis votre ligne durant le mois de mai. Pourriez-vous me confirmer qu'il s'agit bien de consommations data effectuĂ©es avec vos donnĂ©es mobiles et non pas avec une connexion Wifi ?Dans l'attente de votre retour,LĂ©o de l'Équipe Prixtel Bonjour LĂ©o de l'Ă©quipe n'utilise pas le Wifi sur mon vieux tĂ©lĂ©phone....Tiens, le 14 mai, il apparaĂźt une consommation de 1,51 Go .Nous sommes le 17 mai, et c'est toujours 1,51 Go qui apparait, ce qui prouve que le compteur ne fonctionne pas en temps rĂ©el !Et je ne parviens toujours pas Ă  consulter mon espace client sur mon PC, bien que j'aie vidĂ© cache et profite du prĂ©sent message pour dĂ©plorer que je ne puisse converser avec vous par tĂ©lĂ©phone... ce qui est un comble pour un vendeur de tĂ©lĂ©phonie !Je commence Ă  prospecter pour changer d'opĂ©rateur...Bien cordialementJean-LoĂŻc V Bonjour Jean-LoĂŻc,Nous sommes navrĂ©s toutefois nous ne disposons pas de hotline. DĂ©sormais toutes les demandes d'assistance transitent depuis le forum d'assistance ou depuis la rubrique Assistance de votre Espace nous excuser pour le dĂ©sagrĂ©ment liĂ© Ă  votre suivi conso. Nous avons bien pris en compte votre demande et celle-ci a Ă©tĂ© transmise au service concernĂ©. Je reviens vers vous dans les plus brefs ailleurs, je vous invite Ă  vous connecter sur votre Espace Client depuis un autre navigateur internet si le problĂšme de connexion persiste sur votre navigateur habituel. Je reste Ă  disposition,LĂ©o de l'Équipe Prixtel Bonjour Jean-LoĂŻc,Suite au retour du service concernĂ©, celui-ci nous indique qu'une connexion aux donnĂ©es mobiles ayant commencĂ© le 01/05 et s'Ă©tant terminĂ©e le 09/05 a bien Ă©tĂ© remontĂ©e sur votre suivi de consommation. Toutefois pour que votre suivi de consommation soit Ă  jour, il est nĂ©cessaire que la connexion internet soit terminĂ©e. Hors tant qu'une connexion internet n'a pas Ă©tĂ© terminĂ©e, votre suivi de consommation ne change pas ; ce qui explique que vous n'ayez pas eu connaissance du montant de donnĂ©es mobiles utilisĂ©s depuis le 01/ mettre fin Ă  une connexion internet, vous pouvez Ă©teindre les donnĂ©es mobiles, redĂ©marrer votre tĂ©lĂ©phone ou passer en mode avion. Je reste Ă  disposition,LĂ©o de l'Équipe Prixtel
80inSNm.
  • axqq36vwsm.pages.dev/336
  • axqq36vwsm.pages.dev/200
  • axqq36vwsm.pages.dev/511
  • axqq36vwsm.pages.dev/64
  • axqq36vwsm.pages.dev/458
  • axqq36vwsm.pages.dev/457
  • axqq36vwsm.pages.dev/589
  • axqq36vwsm.pages.dev/164

    • compteur internet d octets Ă©mis et reçus