grolamerz inside

Aller au contenu | Aller au menu | Aller à la recherche

lundi 25 septembre 2006

ForTwo, première plus panne

Une descente de trottoir un peu moins douce que d'habitude et hop, la jauge refonctionne normalement.
Je roxx trop la mécanique.

samedi 23 septembre 2006

ForTwo, première panne

Bah vi, déjà. Même pas 10.000 bornes et déjà une panne...

J'avais des doutes sur l'ABS (qui semble avoir du mal à se déclencher) mais là, j'ai mieux, beaucoup mieux.
Je fais le plein et hop, déjà deux bulles de vide. Sur le plein précédent, j'étais passé à une bulle vide au bout de 15 bornes, ça se confirme méchamment.

Donc passage au SC pour récupérer le numéro de l'atelier et prise de rendez-vous dès lundi pour voir ce qui se passe.

Concernant les réhausses de siège, que du bonheur pour le moment : j'ai déjà réussi à me mettre la tête deux fois dans le toit (en sortant, dans le joint supérieur de la portière en fait) et le rétro est désespérement (et dangereusement) trop bas. Les pièces de rechange existent, on va attendre un peu niveau budget.

vendredi 22 septembre 2006

Zimbra, Compaq DL-580 et CentOS

J'ai récupéré un Compaq DL-580 G1 : quad Xeon 700MHz avec 2MB de cache, 4 GB de RAM et 4 HD 72GB en RAID5, une belle bête quoi.

L'usage initial prévu était un Zimbra Professionnal Edition. Mais devant le prix de la RedHat Advanced Server (obligatoire pour Zimbra et le quad CPU), on s'est rendu compte que ce n'était pas jouable (grosso modo 1100 USD en plus par an)... Donc déclassement (si je puis dire) à un Zimbra OpenSource, sous CentOS.

Et là, galère. Oh, pas grand chose, juste une petite galère bien pénible, qui fait perdre une heure : impossible d'arriver à la fin du formatage du volume créé sous CentOS 4.3 (LVM ou pas). Quelques tests complémentaires et je me suis rendu compte que ça marchait avec la dernière version de RHES. Donc tentative sous CentOS 4.4 et c'est nickel !

Un joli grand merci aux gens de CentOS, en particulier à leur système d'installation qui fonctionne (ce qui n'est pas le cas de celui de RHES qui installe KDE and co même lorsqu'on a décoché toutes les cases).

Merci aussi aux gens de chez HP qui ont fait un CD autoboot qui permet de mettre à jour les firmwares de toute la gamme...

lundi 18 septembre 2006

Freins à disques pour le Vattenfall

En suivant des liens de liens de liens (dans des forums), je suis tombé sur un forum de finlandais complètement fada qui ont réalisé un kit de freins à disques pour les ponts de Volvo Cxxx.

Là où c'est vraiment bien, c'est qu'ils utilisent des étriers de Patrol (ça se trouve à la pelle) et des disques ventillés de LandCruiser (pareil).
Là où c'est moins bien, c'est qu'il faut passer au tour la pièce sur laquelle vient normalement se fixer le tambour...

Le thread finnois est ici.
Un bel éclaté pour bien voir la pièce (16) à reprendre est ici.

mercredi 13 septembre 2006

Réhausse siège conducteur Smart ForTwo

Jambes trop grandes + Smart ForTwo = pas confortable...
Siège reculé au max, dossier incliné au max, il reste cet éternel problème des cuisses pas à plat, donc bassin mal basculé donc dos douloureux.

Avec l'expérience passée des réhausses pour le 90" (la première KlugMobile), je me suis dit qu'on pouvait faire la même chose dans la Smart.
Sentiment confirmé parce que j'ai pu trouver en VPC chez MisterDotCom.de (de jolis blocs en alu qui font ça pour 49€ les quatre).

Donc mesure rapide et passage à la GSB du coin pour y acheter un tube de 1m de long (chaque glissière fait pile 50cm) en 35x20 et un jeu de quatre vis (8.8 en 60mm, 25mm des vis d'origine plus l'épaisseur du tube). Découpe à la scie à métaux, pointage (un de ces quatre le gabarit en ligne) puis perçage.

Facile, tout comme la mise en place.

Résultat : je vois l'afficheur (qui était caché totalement par le volant), j'ai relevé le dossier et avancé le siège d'un cran.
Il ne reste qu'à tester sur "longue" distance.

Echo sous Asterisk

C'est lourd, hein...
Là, dans le cas qui nous intéresse, l'écho est ressenti par les extérieurs qui appellent vers des phones analogiques sur une Astribank (pas sur les phones VoIP bien entendu).

Une piste : http://voipspeak.net/index.php?option=com_content&task=view&id=80&Itemid=28

Et une copie locale de l'article :

You've played around with Asterisk and set yourself up a test system and everything works but you go into production with a TDM card connected to the phone lines and now the users are complaining about echo. There wasn't any echo on the old phone system or hooking up an analog phone, and your SIP trunks sound fine, so what is the problem? The actual number of things that can cause echo and how to resolve them all could almost fill a book, instead we are going to look at the most basic echo canceling using the Zaptel drivers. This will solve "most" echo problems but will not work in every case, regardless it is the first tier approach to solving to problem. The procedures outlined in this article will work with Digium TDM analog or TE PRI cards.

You've played around with Asterisk and set yourself up a test system and everything works but you go into production with a TDM card connected to the phone lines and now the users are complaining about echo. There wasn't any echo on the old phone system or hooking up an analog phone, and your SIP trunks sound fine, so what is the problem? The actual number of things that can cause echo and how to resolve them all could almost fill a book, instead we are going to look at the most basic echo canceling using the Zaptel drivers. This will solve "most" echo problems but will not work in every case, regardless it is the first tier approach to solving to problem. The procedures outlined in this article will work with Digium TDM analog or TE PRI cards.

Now granted there are many different types of echo and numerous reasons why you might get echo, this article will focus on the most common which is when users on your PBX are hearing themselves when talking to someone on the other side of an analog phone call. Echo on trunks to ITSP's (Internet Telephony Service Providers) is more often a network problem and these procedures will have no affect on those calls.

As if you didn't expect it, the first thing you want to do is make sure you have the latest code on your machine. If everything else is pretty current, the only updates should be Zaptel and Libpri. As of the time of this writing, I have experienced issues with the current release version of Zaptel (v1.2.7) so we will want to install the SVN version to get the latest and greatest code.

From your Asterisk box use the following commands:

cd /usr/src
rm -Rf zaptel
rm -Rf libpri
svn checkout http://svn.digium.com/svn/zaptel/trunk zaptel
svn checkout http://svn.digium.com/svn/libpri/trunk libpri
cd zaptel
make
make linux26
make install
cd ..
cd libpri
make
make linux26
make install
reboot

Now assuming everything rebooted properly, we can run a quick check to see if things are working properly. From the command prompt type the following command:

ztcfg -v

You should get a status display as follows:

Zaptel Version: SVN-trunk-r1328
Echo Canceller: MG2
Configuration
======================
2 channels configured.

Next we need to make sure our echo settings, these settings are in /etc/asterisk/zapata.conf

The settings we will be looking at are listed below with typical default settings.

echocancel=yes
echocancelwhenbridged=no
echotraining=800
rxgain=0.0
txgain=0.0

Let's take a look at what these settings actually do.

echocancel
Obviously this disables or enables echo cancellation, it is recommended to not turn this off. The yes setting sets the value to 128, this is the number of taps that are used. Each tap is one sample from the data stream. You can specify the number of taps to use as 16, 32, 64, 128, or 256. It is very rare that you need anything other than setting this to the yes setting.

echocancelwhenbridged
This enabled or disabled echo cancellation when TDM calls are bridged. TDM calls should not need any echo cancellation but some people report improved call quality with this option turned on.

echotraining
A common echo symptom is that at the beginning of a conversation there is a good deal of echo and then it fades away as it it trains itself. If this delay is too long, you can adjust the training cycle. The setting is represented as milliseconds and can accept any value between 10 to 4000. Making the setting to low will not enable the system to train properly. I find that setting this to 128 is often a good starting point.

rxgain
This adjust the gain of the inbound signal. While Asterisk will accept any number from -100 to 100 (-100% to 100% of capacity) it is recommended to never put the values to more than -11 to +11 and in some case anything outside of the -5 to +5 range will actually cause audio loss (mostly on the TDM400 cards).

txgain
This adjusts the audio gain for the signal being sent out to the phone line. While Asterisk will accept any number from -100 to 100 (-100% to 100% of capacity) it is recommended to never put the values to more than -11 to +11 and in some case anything outside of the -5 to +5 range will actually cause audio loss (mostly on the TDM400 cards).

One of the first questions commonly asked is "what is the best settings for the rxgain/txgain?" and simply put, there is no "best settings" that will work for everyone. Every installation is different as there is no perfect consistency between telephone line quality, impendence, line length, etc. So how do you know what settings to use to make the system work properly? Well, the zaptel developers have created some handy tools to help us with that. The primary tool we will use is ztmonitor This tool allows us to visually see the audio levels on the RX and TX sides allowing us a guide to adjusting the levels in the zapata.conf file.

The command format is: ztmonitor <zap channel> -v

An example of monitoring zap channel 3 during a conversation is shown here:

root@asterisk1 ~# ztmonitor 3 -v
Visual Audio Levels.

Use zapata.conf file to adjust the gains if needed.
( # = Audio Level * = Max Audio Hit )
<-(RX)-> <-(TX)->
################   *             #########################  *

If those were the maximum levels that we were seeing during a call, we would know that the RX gain is set pretty good but the TX level is way too high. What we are looking for are peaks that don't go past the middle of the meter.

Although this may sound complicated, it is fairly simple to adjust these settings on the fly. My prefered way is to use an SSH client such as Putty to have three sessions open at the same time. One window will have the Asterisk CLI, the second will be running ztmonitor, and the third will have zapata.conf file open in an editor. During the call, if you need to adjust a setting, make the change to the file and save it, then switch to the Asterisk CLI and type the following:

asterisk1*CLI> reload chan_zap.so

This will reload the zap module without hanging up the call. When you have made you adjustment, stop and restart Asterisk just to make sure you have the right settings. With a little practice you should be able to do these basic echo adjustments in just a few minutes.

Again, this will not solve every echo problem, but for the majority of installations we have done, this was all we needed to do to virtually eliminate the echo problems from the TDM and TE connections.