fid = fopen('core.iq','rb');
y = fread(fid,'uint8=>double');
y = y-127;
y = y(1:2:end) + i*y(2:2:end);
x=abs(y);
plot(x);
donne
Six salves probablement identiques dont les deux premières saturent le récepteur. La troisième se trouve encore dans la phase d'adaptation du gain automatique et les trois dernières sont stables.
En zoomant sur la dernière salve
plot(x(1130000:1280000));on obtient: On peut encore zoomer pour avoir une idée du timing d'un bit...
plot(x(1134600:1140000));On a donc, quelque chose comme 1 mS dans le préambule et 500 µS dans les bits qui suivent. En zoomant au plus proche sur un 'bit',
plot(x(1151659:1152144));Et donc, 485 nS de largeur... 2400 bauds aurait donné 417 nS... Faudrait regarder sur la longueur d'une salve... En chipotant en 'C' avec la librtlsdr... Les 6 salves sont bien identiques (à part, peut-être, le préambulle). Une salve resemble à OregonScientific-RF-Protocols-II.pdf suggère que c'est le temps entre deux pulses qui déterminerait si il s'agit d'un '0' ou d'un '1' et que le même message est, en effet, répété un certain nombre de fois pour permettre à l'AGC de s'adapter.
À 250k échantillons par seconde, il y a 300 échantillons entre le préambule et la première impulsion et ensuite, 100 ou 200 échantillons suivant que c'est un '0' ou un '1'. Si on décode les messages pendant un certain temps, on obtient chaque fois cinq octets du genre :
10000110 00000000 01100101 10100101 01010001 10000110 00100000 01100101 11110101 01010001 10000110 01110000 01100101 11100101 01010001 10000110 10000000 01100101 11010101 01010001 10000110 11010000 01100101 11000101 01010001 ou (en échangeant les '0' et les '1') 01111001 11111111 10011010 01011010 10101110 01111001 11011111 10011010 00001010 10101110 01111001 10001111 10011010 00011010 10101110 01111001 01111111 10011010 00101010 10101110 01111001 00101111 10011010 00111010 10101110Il faudrait faire varier un paramètre en essayant de garder les autres constant pour voir à quoi ils correspondent. Déjà, le dernier est constant, il n'y a donc pas de checksum ou de CRC... Ici, seuls les seconds et quatrième ont varié et on dirait que les bits de poids faible sont transmis en premier... A priori, 3 valeurs sont transmises (état des piles, humidité et température).
En traduisant les bits en octets, je ne parviens pas à les corréler avec la valeur affichée... (température en °C, % humidité, octets)
23.5 20 61 01 66 8D 86 23.5 20 61 0B 66 85 86 23.6 20 61 05 66 87 86 23.7 20 61 06 E6 80 86 23.8 20 61 0C E6 88 86 23.9 20 61 09 E6 8C 86 24.0 20 61 02 E6 8A 86 24.1 20 61 0D E6 86 86 24.2 20 61 01 E6 81 86 24.3 20 61 04 E6 85 86 24.3 20 61 0E E6 8D 86 24.4 20 61 0F E6 83 86 24.5 20 61 05 E6 8B 86 24.6 20 61 00 E6 8F 86 24.6 20 61 03 16 80 86 24.6 20 61 03 16 80 86 24.7 20 61 09 16 88 86...Il doit y avoir une erreur quelque part.


































