Title: -Explicaci¢n par metros AX.25- From: EB7CJO@EA7RKC.EACA.ESP.EU To: AX25@EA Hola, despu‚s de varias peticiones por parte de algunos usuarios, he decidi- do escribir este mensaje, que contiene una lista de los principales par metros del protocolo AX.25 con extensas explicaciones de cada uno. Creo que de esta forma se evitar n configuraciones chapuceras y par metros mal ajustados, como por desgracia es muy com£n ver entre los usuarios del packet. Creo que la radioafici¢n del packet comienza por un entendimiento de lo que se est  utilizando, y consiste en un intento de mejorar las condiciones y, en definitiva, superarse cada d¡a en cuanto a la configuraci¢n de nuestra esta- ci¢n. De hecho, la radioafici¢n siempre ha consistido en eso. Puesto que es algo dif¡cil expezar de cero, y sobre todo conseguir la in- formaci¢n adecuada, adem s de ser el ingl‚s una barrera para algunos, creo que este bolet¡n ayudar  a muchos a empezar a realizarse como radioaficiona- dos del packet. A continuaci¢n encontrar s la lista de los par metros del protocolo, organizados de esta forma: a modo de t¡tulo est n los nombres que se le dan a cada par metro, despu‚s explicaci¢n del mismo, y al final los comandos que se emplean en cada firmware. Por supuesto, antes hay que ase- gurarse de que las unidades de tiempo corresponden a las de tu firmware en particular. Entre corchetes ([]) encontrar s el valor recomendado. SlotTime, DWait --------------- Este es el "tiempo de frecuencia libre para transmitir", o sea, despu‚s de que la frecuencia est‚ libre, debe de pasar este tiempo para poder emitir nosotros. Este temporizador act£a en conjunci¢n con otro par - metro: la P-Persistance. Este £ltimo mide la probabilidad de que envi- emos cuando ha concluido el SlotTime. O sea, cuando se libera la fre- cuencia, se espera SlotTime, se calcula la probabilidad, y si tiene ‚xito, emitimos (siempre que mientras tanto la frecuencia no haya sido ocupada por otra estaci¢n). ¨Para qu‚ sirve este timer tan tonto? pre- guntar n algunos. Pues es muy importante en el tema de la compartici¢n de la frecuencia y el "abuso" por parte de algunas estaciones. Con este timer, nos aseguramos de que cuando la frecuancia se libere, no se pongan todas las estaciones a emitir a la vez, pis ndose unas a otras. Esto no ocurre con el protocolo DAMA, as¡ que en ese caso este par metro queda desactivado autom ticamente. Pero normalmente hay que darle un valor no inferior a 80 ms, recomendado que todas las estaciones tengan 100 ms. Firmware TAPR: DWAIT [10] - 0-250 *10ms SLOTS [4] - 0-127 (N§ max. de veces que se espera SlotTime) Firmware TF : W [10] - 0-127 *10ms P [64] - 0-255 (0-100%) Nota: En TAPR 1.1.9 hay que usar ACKPRIOR OFF, PPERSIST ON, y PERSIST 8, no tengo muchos datos sobre esto, as¡ que agradezco colaboraciones. FrAck, Timer-1 -------------- Su nombre de guerra es Frame Acknowledgement (confirmaci¢n de paquete), y establece el tiempo que hay que esperar despu‚s de enviar un paquete, para reenviarlo de nuevo en caso de no recibir respuesta de la estaci¢n contraria. Por esta misma causa, puedes comprobar instant neamente si el valor que has puesto corresponde con el tiempo que quer¡as establecer, de esta forma: haz intentos de conexi¢n con una estaci¢n inexistente, y a continuaci¢n mide el tiempo entre dos paquetes SABM sucesivos. Este pa- r metro es bastante importante ya que si se pone mal (demasiado peque¤o) origina una repetici¢n innecesaria de peticiones, que acabar  haciendo que el destinatario conteste a cada una de ellas el n£mero de veces pe- didas. Si esa respuesta consiste en paquetes Info, se env¡an uno detr s de otro el n£mero de paquetes establecido por el MaxFrame de la estaci¢n contraria, repitiendo esta sucesi¢n tantas veces como peticiones suce- sivas se hayan producido. Ejemplo: YO>TU: RR3 YO>TU: RR3 TU>YO: I03 Datos...... TU>YO: I04 Datos...... TU>YO: I05 Datos...... TU>YO: I03 Datos...... TU>YO: I04 Datos...... TU>YO: I05 Datos...... Como ves, en este caso est  duplicado el env¡o de cada paquete, adem s de forma innecesaria. Puedes comprobar c¢mo esto sucede poniendo un FRACK de, digamos, 1 segundo, en una frecuencia cargada. El valor que suele venir por defecto es 5 segundos, aunque para evitar problemas recomien- do que sean 6. De todas formas, variando este par metro s¢lo estamos estableciendo el valor inicial del FrAck, a lo largo de la conexi¢n se ir  ajustando (suavizando) dependiendo del tiempo de respuesta que se vaya obteniendo. Firmware TAPR: FRACK [6] - 1-15 segundos. Firmware TF : F [6] - 1-15 segundos. El rango 16-65535 ajusta el SRTT, *10ms, siendo FrAck=A3*SRTT (A3=3 por defecto) RespTime, Timer-2 ----------------- O Packet-Response-Timer, es un tiempo que hay que esperar desde que re- cibimos una serie de paquetes-Info y enviamos la confirmaci¢n de llegada de ‚stos. Se suele conocer tambi‚n como Timer-2. Es muy importante te- ner bien ajustado este par metro, ya que un valor demasiado bajo conlleva consecuencias nefastas. Este temporizador debe ser siempre superior al tiempo que se tarda en recibir 1 paquete, que a 1200 bps y con un PacLen de 256, es m s o menos 2 segundos (contando los datos de la cabecera). Si es menor que 2 segundos, entonces nuestra estaci¢n enviar  un paquete RR de confirmaci¢n por cada paquete Info recibido. Creo que est  claro que esto no s¢lo es superfluo sino que puede provocar una repetici¢n in- cesante de paquetes ya recibidos. Esto ocurre porque mientras que se es- t  recibiendo el siguiente paquete, el temporizador acaba y se env¡a a la cola de paquetes pendientes un paquete RR confirmando el primero que lleg¢ (y por consiguiente pidiendo el segundo). Pero el segundo paquete est  siendo enviado en esos momentos, por lo que esa petici¢n ser  innecesaria cuando llegue a emitirse. Un ejemplo: YO>TU: RR1 TU>YO: I01 TU>YO: I02 -- mientras se recibe, acaba T2 y se genera un RR2 TU>YO: I03 -- idem, se genera un RR3 YO>TU: RR2 YO>TU: RR3 YO>TU: RR4 TU>YO: I02 -- redundante TU>YO: I03 .... En el TFPCX esto no ocurre casi nunca ya que est  protegido contra estas situaciones. Pero el TFX hace exactamente esto cuando le ponemos el Resp- Time a un valor muy bajo. Solo que en pantalla el orden de los paquetes no es el mismo con el que son enviados. El RR2 aparecer¡a justo despu‚s del I01, pero se env¡a realmente cuando la frecuencia est  libre. Firmware TAPR: RESPTIME [30] - 0-250 *100ms Firmware TF : @T2 [100] - 0-65535 *30ms LinkTime, Timer-3, CheckTime ---------------------------- Tambi‚n llamado Link-Inactivity-Timer (temporizador en inactividad del enlace), es un temporizador que empieza a contar marcha atr s cuando, como su nombre indica, no hay actividad en el enlace establecido. O sea, cuando una estaci¢n no est  enviando nada a la otra, ni recibiendo. El valor que suele venir establecido son 3 minutos. Sin embargo, acon- sejo ponerlo a 1 minuto, por la raz¢n que explico a continuaci¢n: en caso de que el enlace sea de mala calidad, muchas veces las dos esta- ciones conectadas permanecen largo tiempo en espera sin hacer nada, aun cuando se est  realizando una transferencia de datos entre ambos (o sea, paquetes Info). Entonces una espera muy larga originar  pausas muy gran- des, lo que puede minimizarse disminuyendo el Timer-3. Poniendolo a 1 minuto, nos aseguramos de que la espera m s grande ser  de 1 minuto. No est  mal para una frecuencia compartida, y un paquete RR cada minuto como m¡nimo, no supone carga alguna innecesaria. Hay situaciones peores. Firmware TAPR: CHECK [6] - 0-250 *10 seg Firmware TF : @T3 [6000] - 0-65535 *10ms Soft-DCD -------- Este par metro es bastante conocido, aunque pocos saben el valor correcto que se le debe dar. El DCD (Data Carrier Detect) es un pin del puerto serie que se activa cuando est n llegando datos. Esto es lo que se co- noce como Hard-DCD (DCD por Hardware), y son pocos los modems o TNC que lo incorporan. Otra forma de detectar el DCD es mediante el Squelch de la emisora, cosa que a veces tambi‚n se llama Hard-DCD, aunque su nombre correcto es Transiciones de Datos. Tiene la diferencia de que no se est  usando el pin DCD. La £ltima forma es Soft-DCD, que consiste en que se "adivina" si lo que se est  recibiendo son datos v lidos o s¢lo ruido, mediante software. En este caso el Squelch de la emisora est  abierto. Normalmente hace falta un ajuste de sensibilidad. Firmware TAPR: SOFTDCD [OFF] - ON/OFF, ON: no usar el Squelch, OFF: usarlo. Firmware TF : @C [0] - 0-63, 0=usar el Squelch. Si se desea usar el Soft-DCD, se recomienda 25 o menos. (S¢lo TFX) : @D [2] - 0=FullDuplex (no DCD), 1=pin DCD, 2=usar Squelch, 3=Soft-DCD. Ajuste de sensibilidad entre 4 (4%) y 100 (100%), recomendado 50. InfoPoll -------- Tambi‚n llamado IPoll, es uno de los pocos "inventos" que se han hecho para mejorar algo el rendimiento del AX.25. De hecho, en la versi¢n 2.0 del protocolo (1984), esta forma de actuar no est  contemplada, por lo que se puede considerar algo "ilegal", en la pr¢xima versi¢n del AX.25 posiblemente se incluir  algo como esto. Consiste en un peque¤o truco para saltarse las pausas que a veces se producen debido al env¡o de pa- quetes RR de b£squeda (Poll). En lugar de enviar este paquete, se en- v¡a un paquete Info para ir adelantando trabajo, el cual sirve tambi‚n de RR. No conviene enviar siempre un paquete Info en lugar de un RR de- bido a que la longitud de los primeros exceden con mucho a la de los RR. Por ello, se establece una limitaci¢n del tama¤o del paquete que puede ser enviado como "Poll". Se recomienda no pasar de 128 bytes. Firmware TAPR: ? Firmware TF : @I [128] - 1-256 bytes, 0=no usar IPoll. Por ahora eso es todo, si tienes problemas con alg£n otro par metro puedes ponerme un mensaje, con gusto intentar‚ ayudarte. De igual forma, si ves que he metido la pata con algo no dudes en coment rmelo con un mensaje. No conoz- co bien el firmware TAPR, pero me he apoyado en alguna informaci¢n que tengo de ‚l para hacer las equivalencias con los comandos TF. Perd¢n si alg£n usua- rio de TAPR se ve algo discriminado... :-)