Archives par mot-clé : K9W

Antennes, DX, HAM Radio

Suite des considérations sur mes antennes

Comme je vous en parlais il y a peu, j’ai du démonter ma directive Moxon 15 mètres par crainte de l’arrivée d’un typhon (http://xv4y NULL.radioclub NULL.asia/2013/11/06/typhon-en-approche-demontage-des-aeriens/). Sans surprise, bien que celle-ci ne montrait pas de signes apparents de faiblesse et fonctionnait encore à 100%, elle n’a pas aimé le démontage. Plusieurs des éléments qui la constituent sont en plastique et deux ans de soleil sub-tropical les a mis à rude épreuve. Je vais donc devoir la remettre à neuf avant de la réinstaller sur le toit, en essayant de corriger quelques uns de ses défauts minimes.

Antenne quart d'onde verticale canne à pêche bande 20m (http://xv4y NULL.radioclub NULL.asia/wp-content/uploads/2010/08/100_2497 NULL.jpg)
Vue depuis l’arrière de la maison

J’avais aussi démonté la verticale 20 mètres qui était en tête de mât pour lui faire une petite maintenance. Elle disposait de 2 brins radiateurs pour le 20 mètres et le 12 mètres (http://xv4y NULL.radioclub NULL.asia/xv4tuj-station-radioamateur-en-ok20ua/quart-donde-verticale-canne-a-peche-sur-20m/), ce qui lui donnait une couverture du 20 mètres au 10 mètres grâce à la boîte d’accord intégré du TS-590s. Je me suis dit qu’en lui ajoutant un morceau de fil de cuivre de 1,50m de long, je pourrais peut-être couvrir le 6 mètres aussi. Ce matin je l’ai remonté sans difficultés et j’ai rapidement fait quelques essais (dont un QSO avec K9W sur 17 mètres). La résonance à bougé sur presque toutes les bandes, mais je ne sais pas si c’est du au radiateur supplémentaire ou au fait que l’antenne est plus basse (plus proche de la charpente métallique). J’arrive maintenant à l’utiliser sur 50 MHz avec un ROS proche de 2:1 ce qui se règle sans histoire avec la boîte d’accord. Par contre, j’ai perdu tout possibilité d’utilisation sur 28 MHz, impossible de trouver un accord!!! A choisir entre le 10 mètres et le 6 mètres, pour moi c’est clairement la première bande qui l’emporte. Je vais toutefois la laisser un peu comme ça et voir ce que peut donner le 6 mètres en ce moment du cycle. J’ai déjà atteint le DXCC sur cette bande et elle ferme tôt à cette saison.

Choke balun coaxial (http://xv4y NULL.radioclub NULL.asia/wp-content/uploads/2011/11/100_3046 NULL.jpg)Pendant deux jours je me suis retrouvé avec le dipôle 80 mètres OCF (antenne type FD4) (http://xv4y NULL.radioclub NULL.asia/2011/12/06/ocf-dipole-80m-epilogue/) comme seule antenne. Bien que plutôt bas par rapport au sol, il a des performance honorables sur les bandes basses comme l’a prouvée la soirée d’hier avec des ouvertures simultanées vers l’Amérique du Nord, l’Europe et bien sûr l’Asie. Par contre, j’étais stupéfait de ses bonnes performances relatives sur 20, 17 et 15 mètres! N’ayant que cela comme antenne, je m’en suis servi pour faire des contacts avec les expéditions T33A (http://www NULL.t33a NULL.com/) et K9W (http://www NULL.wake2013 NULL.org/). D’accord ces expéditions ne sont pas trop éloignées, mais je me retrouvais face à un pile-up de japonais tout aussi proche et bien mieux équipés! Sur 12 mètres et 10 mètres elle est inutilisable. Je pense que la bobine d’arrêt “ugly-balun” pour les courants de mode commun en est la cause car elle présente une impédance trop importante sur ces bandes là. Je n’ai toutefois pas de raison de la remplacer car en principe la verticale est utilisée pour les bandes hautes…

Contests, DX, HAM Radio, Propagation

Prédictions de propagation et stratégie pour les concours radio par K6TU

Cela fait déjà un petit moment que je voulais faire un article sur ce service mais il était resté inachevé dans les brouillons. Une annonce vue récemment le concernant (mais j’ai oublié où) m’y a fait repenser.

Les avis divergent sur le sujet, mais pour certains OM amateurs de concours radio, la victoire passe par une planification rigoureuse de ses opérations. S’il va de soit que faire tourner une équipe de 20 opérateurs pour 8 stations demande de l’organisation et donc de la planification, d’autres OM (et pas les plus mauvais contesters) vous diront qu’il faut toujours être sur la bande la plus haute ouverte et ne descendre que si le rythme chute vraiment.

Stu de K6TU a lui fait son choix. Participant assidu à de nombreux concours et même vice-président du Nothern California Contest Club, il a depuis longtemps utilisé des outils comme VOACAP pour réaliser ses prédictions de propagation et planifier sa stratégie (ou souvent celle des copains) pour les concours. VOACAP est un outil reconnu de modélisation de la propagation et ses prédictions sont tout à fait pertinentes (mais elles ne restent que des probabilités). Il a toutefois un le défaut d’être long à paramétrer et de nécessiter une mise au point rigoureuse pour réellement donner de bons résultats. C’est là qu’intervient K6TU qui lui a développé des outils d’aide à la stratégie pour les concours, transformant de manière automatique les informations brutes de VOACAP en données utiles pour les contesters (http://k6tu NULL.net/).

Les services qu’offre le site web de Stu sont payants, l’abonnement est de 29,99$ pour 12 mois (http://k6tu NULL.net/?q=Pricing). Toutefois il existe une offre de période d’essai gratuite pendant 30 jours. Ensuite, certains services restent gratuits pour tous les utilisateurs enregistrés, même s’ils ne sont pas à jour d’abonnement. Si vous ne souhaitez pas vous enregistrer, vous pouvez aussi accéder aux service gratuit de prédiction pour les futures DXpéditions FT5ZM ou K9W, dont le résultat pour ma station est affiché ci-dessous.

Prédiction propagation K9W - XV4Y par K6TU (http://xv4y NULL.radioclub NULL.asia/wp-content/uploads/2013/10/Propag_K6TU_XV4Y_30-Sep-2013_02-20-50_UTC_00_ut NULL.jpg)

Contests, Dev web, DX, Ego, Geek, le monde est geek, HAM Radio

QScope avec K9W et TO2TT

Logo QScope.org (http://xv4y NULL.radioclub NULL.asia/wp-content/uploads/2013/08/logo_qscope_b NULL.png)En ce moment j’ai peu de temps pour le blog. Mes diverses activités professionnelles prennent la première place, avec entre autres un projet d’ouverture de restaurant qui redevient d’actualité. Ensuite j’ai été pas mal sollicité sur QScope (http://www NULL.qscope NULL.org/), d’abord par des nouvelles statistiques suggérées par les utilisateurs, ensuite par les bogues à corriger puis finalement par des revues et bulletins DX qui souhaitent avoir plus de détails afin de publier un article complet sur le projet.

La bonne nouvelle c’est que les organisateurs de deux grosses Expéditions à Wake Island (K9W) (http://www NULL.wake2013 NULL.org/) et à Mayotte (TO2TT) (http://www NULL.i2ysb NULL.com/idt/) ont annoncé leur volonté d’utiliser QScope en interne pour l’organisation de leurs opérations. Les statistiques produites leur permettront d’avoir jour par jour toutes les informations pour mieux répartir les tours d’opérateurs et la répartition des activités par bandes et modes dans le temps. Le but étant de maximiser le nombre de QSOs afin de mieux “rentabiliser” le coût de ces organisations. Le nombre de QSOs pour de telles DXpeditions en fin d’opération s’élève vite à 100.000, et ces utilisateurs utiliseront les statistiques les plus coûteuses en terme de temps machine!

J’ai donc du passer du temps afin de “préparer l’avenir”. En effet, si maintenant l’application compte 600 utilisateurs enregistrés et plus de 3 millions de lignes de log téléchargées, l’effervescence des premiers jours s’est calmé en moyenne il y a 10 utilisateurs “actifs” par jour qui produisent des statistiques et 1,8 millions de lignes de log dans la base de données (les utilisateurs effacent souvent leur logs après avoir produit les statistiques). La base de données principale fait 250 Mo, et les index occupent autant. Quand on tient compte de la RAM du serveur occupée par le système, le SGBDR lui-même et les différents shared buffers, on se rend compte qu’on se rapproche vite de la capacité maximale disponible de 1 Go actuelle sur le serveur. Rapidement, au lieu de lire les données dans la mémoire cache rapide, c’est sur le disque dur très lent que le SGBDR ira chercher ses informations à traiter. Les temps de calcul seront multiplié par 10 au moins…

Deux solutions à cela : augmenter la RAM du serveur ou mieux répartir les données. La première solution est la plus rapide à mettre en oeuvre, le problème c’est que chez le fournisseur que j’ai choisi c’est aussi la plus coûteuse. Les prix sont très attractif pour l’entrée de gamme, mais ensuite on grimpe très vite. L’autre solution est donc beaucoup plus intéressante sur le long terme. La réponse que je souhaitais mettre en place s’appliquait en trois phases :

  1. Mettre en place le mécanisme de Paritionnement de Tables de PostgreSQL. Simple à mettre en place en théorie, même si entièrement manuel contrairement aux SGBDR commerciaux comme Oracle ou Sybase, il permet de diminuer la taille de chaque table à charger en RAM et la taille des index. Je pensais donc répartir mes utilisateurs sur 27 tables (les 26 lettres de l’alphabet plus un “fourre-tout”) en fonction de la première lettre de leur indicatif. Après quelques tâtonnements (une maquette avec 2 utilisateurs est bien plus facile qu’une base de production avec 600 comptes) tout fonctionnait parfaitement. Les tables les plus grosses faisaient 40 Mo et les index avaient bien diminué en taille. Le “hic” c’est que les performances étaient pires qu’avant!!! Le problème venait de la fonction choisie pour répartir les utilisateurs sur les différentes tables. Celle-ci était coûteuse en temps machine et la pénalité se paye à chaque requête. J’ai donc du faire marche arrière… Le partitionnement reste intéressant, mais pour une répartition plus légère à calculer (simple comparaison) comme celle sur une date.
  2. Donner la possibilité d’attribuer à chaque utilisateur une base de données différente. Là, le travail se résumait à pas mal de réécriture du code existant pour permettre de se connecter sur différentes base de données “à la volée”. Rien d’insurmontable surtout que j’avais envisagé la chose assez tôt. En pratique ça me permet d’isoler facilement les “gros” utilisateurs comme les DXpeditions. Ils feront leurs calculs gourmands sur une base de taille plus petite que la base principale, diminuant les temps de traitement. La compartimentation au niveau du serveur aidera aussi les utilisateurs de la base principale à être moins impactés puisque ce seront deux emplacements mémoire et deux emplacements disques différent qui seront consultés, limitant les phénomènes de “lock“.
  3. Permettre d’utiliser plusieurs petits serveurs plutôt qu’un gros. Techniquement la solution est la même que la précédente, sauf que cette fois-ci au lieu d’interroger une autre base de données du même serveur je vais la chercher sur une autre machine. Cela est très intéressant car en répartissant les utilisateurs sur plusieurs bases on évite que celles-ci grossissent de trop et deviennent trop lourdes à gérer. Du point de vue financier, c’est aussi le plus intéressant car en doublant le coût, on double réellement la capacité (CPU, RAM et disque) alors que dans la grille tarifaire du fournisseur, doubler le prix payé pour le serveur ne faisait que doubler la RAM. Le contrecoup c’est que ça fait deux systèmes à gérer et donc plus de temps à passer. Toutefois, si les deux systèmes sont identiques et disposent de bonnes procédures automatisées, cette maintenance reste limitée.

Comme vous le voyez, je suis assez satisfait du temps passé sur QScope car cela me permettra de répondre plus facilement à l’augmentation de la demande qui va venir avec la saison des concours et des DXpeditions. L’échec de la mise en place du paritionnement n’est que partiel, et dans la réalité le serveur se comporte mieux que je ne l’avais craint. En effet, en plus de la RAM physique de 1 Go qui est allouée, 4 Go de disque SSD très rapide sont vus par le système comme de la RAM et permettent de diminuer les temps de réponse du disque tant qu’on reste dans des limites acceptables.