Finally, I have been able to analyse the output of a Mobile Station and compare it to the output of a DDX+MGV105.

After a couple of tests, it was clear, as expected that the signal from the MS (hereafter) was quite different to the signal coming from DDX, especially with regards to the distribution of packets.

The voltage and timing were similar, except for the pause between double packets.

At this point, I needed a logic analyser to check the content of the packets and since I do not have an easy access to an oscilloscope at work, obviously I do not have one at home, and I needed a good set of samples, I decided to ‘build’ something that without having the quality of an oscilloscope, enables the recording of a high number of samples.

With a couple of resistors the voltage coming from a MS or a MGV105, can be reduced to meet the maximum acceptable levels of a sound card (normally between -1V and 1V). In the Internet there are a lot of examples on circuits to adapt the signal that is going to be recorded, protecting the sound card and PC. In my case, and since this solution was prepared ad-hoc to solve the problem with the crane, I simply used a simple voltage divider.

Choosing the resistors is critical, especially if you do not know the circuit in the sound card. As a general rule the second resistor should support only the -1V,1V difference, and the current through the divider should not be high enough to destroy the resistors.

Personally, I do not know if a high impedance in the divider would be better than a low impedance (as I said I do not know the details of the sound card). I have the feeling that a low impedance would be better… but it would require to dissipate a lot of power, and this solution was design to be built with 0,25W resistors. All in all, I used the following schema.

Playing with different values for the second resistor, the best results in my case were with 33k – the limit to saturate my sound card and get voltages close to -1V,1V. Note that a higher resistor can damage a soundcard; actually 33k is already too high… especially for the MGV105.

As explained before, this was just an ad-hoc solution; there are much better circuits to adapt the signals.

The software used to record the signal was wavosour. Any software that can record at the maximum sample rate supported by a sound card is OK. I used the “line in” port of my sound card, but I suppose the microphone port could work too.

The higher the sample rate is, the best (you get more samples to capture the signal). Since the Motorola format has a frequency of ≈38K[1], a sample rate of 44K could be enough (you get a sample each ≈22us and the shortest pulse in the format for locomotives is ≈26us). However, higher sample rates are needed in order to obtain an accurate capture, (pretty important if you want to measure the timings, and not just to capture the levels). In addition, higher sample rates enable the recording of accessory packets, which shorter pulse is ≈13us – out of the scope of this analysis.

I recorded the signals from the MS and DDX+MGV105 (configuring rocrail to work only with MM) using 192K as ample rate – once again I had no idea of what the limits of my sound card were.

The resulting wave files can be opened and treated with Matlab. To that end I wrote a set of functions to prepare the signal (chose the channel in the case of a stereo recording, produce the sampling vector and even adapt the polarity of the signal); decode the trits and measure the distance between packets; decode the bits; and measure the distance between two data cursors in a figure.

The results for idle data in a group of 4 packets in DDX can be found hereafter. Besides the the way the information is distributed in the MS, and not considering the expected differences –i.e. no idle data for DCC in the MS, unknown packets in the MS that could be MMX info – the main differences were on the pause timing between packets, specially the pause between double packets.

The MS is forcing a pause of more than 6000us, whilst DDX is forcing only 2000us (1700us reading the source code, if I am understanding it right).

On the other hand, the timing of an idle packet in DDX is similar to the timing of the MS, though the MS is not producing the expected idle packet -i.e. AAAA00000’trit.

With this first analysis and the results of the different functions in Matlab, the most significant difference seemed to be on the pause between double-packets. Furthermore, the comments on the different configurations for the Intellibox, and the comments on how the 6021 can be also configured to adapt the timing between packets, pointed at the timing as the more probable cause of the problem with the crane.

As a first solution I have modified the end19K value at locpool.c in rocrail sourcecode, 6000us instead of 1700. With this figure, the crane is reacting fine. I have tested the other MM decoders I have (tams LD-W-3, and a MMX decoder) and everything still works. I have also tested if this modification affects to the DCC signal,  and so far I have not detected any problem with my home made DCC accessory decoder and the loksound decoders.

I would expect more flickering in the lights, and of course a longer delay in the response to commands… but it does not seem to be so critical. Obviously, this is just a working solution. At least it would require a dialog in rocview to offer the possibility to change this value or not (as the intellibox or the 6021 do).

I am working now in declaring a new MM format in DDX (MM6) forcing this special pauses of 6000us. As soon as I get results, if any, I would publish them.

The files in matlab as well as the modified locpool.c can be found attached. Sorry but the comments are in Spanish, so if you want to use them and you need translation, please let me know.

En realidad el mecanismo es sólo el juego de bobinas para conmutar los cambios de aguja, la parte de digitalización hay que ponerla aparte a través de un decoder. Mi idea era utilizar las dos placas de decoders v2.0  que hice ya hace algún tiempo. Sin embargo, al hacer las primeras pruebas tuve algunos resultados no previstos y acabé quemando 4 veces la placa, en concreto el microcontrolador y el array de darlingtons.

Tras  volverme loco, probar con diferentes versiones de firmware, con diferentes boosters e incluso probar la placa v3.0, obteniendo siempre resultados extraños (desde más elementos quemados hasta placas que no respondían), finalmente, gracias a un amigo electrónico creo que he conseguido tener alguna idea del porqué de estos comportamientos raros.

Midiendo la resistencia de una bobina tradicional, de las que iban incluidas en las vías M, se tiene un valor de 30 Ohms, mientras que las nuevas bobinas, visiblemente más pequeñas, ofrecen una resistencia de sólo 12 Ohms. Como resultado, además de tener un bobinado más pequeño para mover el mecanismo, y que por lo tanto puede requerir más corriente, para una misma caída de tensión de 18-20V, la corriente que se debe ofrecer al bobinado es mucho mayor.

Como resultados de esta campana de pruebas, si el array Darlington sólo puede dar 0,5A, en las pruebas acababa por quemarse. Solución:

• Evitar el uso de la fuente de 20V, ya que incluso puede ser excesiva para las bobinas tradicionales.
• Soldar un nuevo Darlington encima del que lleva la placa, de forma que puedan drenar 1A.

• Incluir una resistencia en serie antes del bobinado. Hice pruebas con los valores de la tabla, y el máximo valor aceptable era de 8,2 Ohms. Además, y por precaución leí que era conveniente proteger los bobinados en su desactivación mediante un diodo en paralelo, con lo que hice el siguiente montaje:

Para conseguirlo fabriqué una nueva serie de cuatro decoders. Se trata de una versión ligeramente diferente a la 3.0, acomodando los conectores para que sea más sencillo tirar el cable por debajo de la maqueta.

Archivos v4.0.

Quizás la diferencia más importante venga por el microcontrolador utilizado en algunos de los decoders implementados. He comenzado a migrar del viejo pic 16f84A al 16f628A. Buscando en internet no queda claro si el antiguo va a ser discontinuado próximamente, y si el 16f628A es su substituto – de hecho existe un pic de similares características más nuevo todavía, el 16f88. Lo cierto es que a fecha de hoy, el 16f628A es el más barato de los tres, casi dos euros de diferencia con respecto al 16f84A. Multiplicando por 10, son casi 20€ de ahorro.

Por lo demás, el nuevo microcontrolador tiene más capacidades, que yo no voy a utilizar en el diseño de los decoders, y la migración es bastante sencilla, ya que el patillaje es compatible entre ambos pics y lo único que hay que hacer es cambiar el firmware – mover los registros de usuario, la forma de trabajar con la eeprom y desactivar los comparadores. El nuevo firmware, 7.01, es idéntico al utilizado para el 16f84A. Mismas funcionalidades pero con los cambios necesarios para correr sobre el nuevo microcontrolador.

Version 7.01 para pic 16f628A. 

 La verdad es que ya no sé si tras la detección, la información se volcará a un bus s88, a loconet, o si me haré yo algún tipo de solución propietaria para reducir el cableado.

Lo que quería probar primero era cómo hacer un sistema de detección que fuera inmune a la luz ambiente. Esto es, que tuviera mucha sensibilidad para detectar un tren, pero que la vez desestimara los positivos por luz directa, en lugar de por reflexión.

 La solución me la dio opendcc y es bastante sencilla:

1. Con ayuda de un PIC se genera una señal 01010 y se manda al emisor IR.
2. En cada ciclo se mide la tensión en el receptor infrarrojo.
3. Si la tensión viene porque el circuito se activa por la luz ambiente… el circuito se habrá activado siempre: 11111… es decir, evaluando la tensión recibida en el receptor, la suma de tensiones (o su media) en los periodos 0 será mayor que en  los periodos 1
4. Si por el contrario la detección viene por una reflexión, se tendrá: 01010, y la suma de la tensión en los periodos 1 será mayor que en los ceros.

La tensión en receptor se evalúa con un conversor analógico digital puesto que los niveles de detección pueden depender de la cantidad de luz ambiente existente… y por lo tanto es difícil fijar que valor de tensión equivale a 1 y que valor equivale a 0. Éste es un punto en el diseño que aún no he cerrado, De hecho existen una serie de variables que se pueden todavía optimizar para mejorar la detección. 

Por un lado tenemos que en un circuito clásico de detección – como el que sugiere las hojas de catálogo del sensor que utilizo, CNY70 – las dos variables que se manejarían son la resistencia en el emisor, y la resistencia en el receptor.

Con mis conocimientos amateur de electrónica, en general interesa tener una resistencia baja en el emisor y alta en el receptor.

• Rd lo más baja posible en el emisor para que circule toda la corriente posible sin quemar el led: en este caso si el máximo que soporta es 50mA, con lo que da una caída de tensión de 1,25-1,6V. Poniéndonos en el caso peor, y buscando una corriente de 40mA para dar un poco de margen de seguridad, tenemos:

Rd=(Vcc-Vf)/If=85-93Ohms

Para estar en el caso más restrictivo habría que elegir el valor mayor. En mis pruebas, me he ido a una Resistencia de 390 Ohms (lo más bajo que tenía por casa), con lo que la corriente que circulaba variaba entre 8 y 9 mA… obviamente he de hacer pruebas con una resistencia más acorde (100Ohms?). El problema futuro será como alimentar un juego de 8 leds emisores desde una única salida de un PIC, que sólo entrega 5V y 25mA – ni en serie ni en paralelo sería capaz de entregar el voltaje o la corriente suficiente (≈3mA por Led)

• Rt lo más alta posible en el receptor para aumentar la sensibilidad. Por poca corriente que llegue al receptor, se traducirá en una caída de tensión importante. Esto es necesario porque el pic evalúa la tensión en un margen de 0 a 5V (una precisión de ≈0,005V), y lo interesante es tener la mayor diferencia entre la detección del símbolo 0 y la detección del símbolo 1. 
  • Una opción sería modificar la tensión de referencia del conversor A/D en el pic, para que, por ejemplo, se evaluara de 0 a 1,5V… Aún no lo he descartado, pero esta solución implicaría más componentes y perder un pin en el pic (el que se usa para obtener Vref)
  • Otra opción sería usar una resistencia adecuada. Para el cálculo se puede usar la siguiente gráfica y estimar la distancia a la que queremos que se produzca la detección.

  

El problema es que esta gráfica considera unas condiciones muy favorables con una superficie lisa de detección. En cualquier caso sirve de guía, ya que nuestra detección se encuentra en el entrono de los 10mm… Poniéndonos en un caso catastrófico con una corriente de 0.001 mA, una resistencia de 1M, nos daría una caída de 1 V (demasiado poco). Con estas consideraciones comencé a probar 1K, 10k, 100k y 1M. Los resultados, como se esperaba eran mejores cuanto mayor era Rt.

Una característica adicional a considerar es que el sensor sí que recibe reflexiones no provenientes de un vagón detectado, por ejemplo de la vía. Obviamente estas reflexiones (falsos positivos) inducen una caída de tensión menor que la del vagón… y deben ser descartadas. Así que no sólo interesa optimizar Rt para que el valor del símbolo  “1” esté lo más lejos posible del valor del símbolo “0”, también hay que garantizar que el valor del “1” detección, esté lo más lejos posible del valor de “1” falso positivo.

De hecho con con 1M existía siempre una diferencia de casi 3V entre el ambos valores en diferentes condiciones de luz ambiental.

Para evaluar que es un falso positivo he hecho un pequeño programa de calibrado en el pic, que mide 50 veces la señal que se recibe al mandar un 1 al emisor cuando no debería haber reflexión. Esta medida debería hacerse en ausencia de luz, puesto que lo que se quiere medir es la luz que proviene del emisor, y no la ambiental. El máximo captado, es el valor límite que se utilizará para desestimar los falsos positivos. Otra opción  – más potente y a  explorar – sería medir la diferencia de tensión entre “1” y “0” en el falso positivo para desestimarla cuando se tiene una detección real. Esto es más potente porque se mantiene el principio de inmunidad a la luz ambiental. Con luz tenue en el primer caso se podría tener una situación en la la luz ambiental ayuda a superar el umbral, sin saturar, dando un falso positivo… si lo que se desestima es la diferencia de tensión proporcionada por la falsa reflexión, es sistema será más robusto. De momento las pruebas se han hecho con el primer supuesto… con lo que aún hay espacio para mejorar.

 El problema al integrar el PIC en el circuito, se hace más interesante.

 Leyendo el catálogo del pic, la resistencia de carga del conversor AD no debería superar los 10K… de hecho con 1M, aunque como comento da una caída de tensión muy adecuada… el sistema no funciona, el PIC no consigue capturarla. Así que para las pruebas he tenido que rebajar a 100k (aún fuera de especificación). La solución si quiero seguir usando una resistencia alta será usar un seguidor de tensión con un operacional o con un transistor – esta parte he de mirarla en detalle repasando mis apuntes de electrónica. Probablemente un operacional será lo más adecuado… pero veré que tengo por casa para hacer pruebas.

 Y todavía quedan más variables a optimizar:

• El tiempo de refresco entre actualizaciones de estado, que afecta para saber si el vagón será detectado atodas las velocidades. El tiempo de la captura AD es prácticamente despreciable (0,1ms-1 canal; 0,8 ms-8 canales), pero para dar tiempo al que el ciclo 01010 se propague de forma correcta he tenido que poner un retraso de 10ms (50ms por canal, 200 ms en 8 canales). Esto podría traer problemas, pero en las pruebas, cualquier cosa por debajo de 1ms daba problemas. Quizás deba jugar más con eso, en especial si considero 8 canales y luego me decido por un bus s88. Lo primero será hacer una prueba con un vagón en movimiento. Opendcc hace unos cálculos que no termino de entender:

“This evaluation is done every 10ms for a sensor. Assuming a train traveling with 50km/h (scale H0). it will travel 16cm in one sec. Thus, the query interval is 1.6mm.”

• La carencia entre detecciones. Para tener un resultado más estable he introducido un tiempo de espera entre detecciones positivas. La idea es que si el sensor es muy sensible, no deje de detectar el vagón demasiado pronto. No sé muy bien como funcionará esta solución en 8 canales. Por un lado no puede tener el pic parado mucho tiempo – se podría solucionar con contadores o vigilando el reloj. Por otro lado hasta que no pruebe con un tren en movimiento no sabré si realmente hará falta este tiempo de carencia – especial me preocupa que pasa entre, idealmente, el sensor debería ser suficientemente sensible para detectar el enganche.

Resumiendo, antes de pensar omo se volcará la información a un bus, hay que  optimizar a nivel de sensor: Rd, Rt, umbral falsos positivos, tiempo refresco y carencia.

La idea, cómo he comentado en otras ocasiones , es generar las señales de control por el puerto serie de un ordenador mediante algún programa como DDW o Rocrail.

En este caso me he decidido por el prototipo MGV-105 de Peter Giling, miembro del proyecto de Rocrail.

La verdad es que es un diseño muy elegante, y bastante más simple que el original ORD-1. Algunos puntos clave:

• Soporta DDC y Motorola
• Lleva un booster de 3A
• Detecta cortocircuitos
• Proporciona información y control por el bus loconet.

Por el contrario, el diseño deja fuera el módulo s88, ya que está pensado para funcionar en un sistema con loconet como buffer de detección de trenes. También se deja fuera la posibilidad de tener una salida para una vía de programación.

Si tuviera que modificar el diseño probablemente retomaría la idea de la programación, y partiría del ORD-2, que básicamente tiene el mismo diseño que el mgv-105, pero con una salida regulada de mayor calidad.

La construcción ha supuesto mi primera placa a dos caras. La lista de componentes y ficheros (pcb, esquemático y firmware) pueden encontrarse en la página de rocrail.

Yo os dejo algunas fotos del montaje:

De hecho han creado una nueva placa de alimentación muy compacta y sencilla que no incluye el bus s88 y que es capaz de reportar cortos y estado a loconet.

Aún no tengo muy claro como funciona el sistema – me estoy informando en el foro de rocrail – pero la versión simplificada del nuevo esquema debería ser algo así.

Lo único que sé es que los cirtuitos que se emplean son bastante más sencillos de realizar, y que el programa es capaz de gestionar los boosters de manera individual.

Lo que aún no sé cierto es como se conectan los detectores de corriente – y si podré adaptarlos a una detección por infrarrojos – ni como se conectan varios boosters.

Espero aclarar las dudas pronto.

La instalación del fumígeno es una odisea que no ha terminado todavía. He tenido que aislar bien el espacio que la máquina tiene reservado para el fumígeno. Primero intenté poner una pequeña pieza d plástico con una zona de contacto para cerrar el circuito… pero no daba buen contacto.

Al final opté por dejarlo todo bien aislado y soldar directamente el cable al fumígeno. Por desgracia, el fumígeno que tenía disponible – un seuthe 11 – no da la cantidad de humo que me gustaría, así que he decidido encargar un seuthe 10 a JCTREN. La diferencia entre uno y otro, para los que desconocen la marca es que el 11 está pensado para la alimentación desde el decoder y el 10 desde la vía (modo analógico). ESU (loksound) recomienda emplear estos últimos cuando el retorno de corriente se ahce directamente por la vía, como es el caso.

De momento he dejado instalado el nº 11 que algo de humo sí que hace, pero en cunato me llegue le nuevo lo cambio.

 Para el camuflaje del decoder me he decidido a eliminar por completo la placa de conexiones que me hice, soldando directamente el decoder a cada uno de las funciones. El resultado es que el decoder casi cabe con la pieza de simulación de carbón original de la máquina.

 La solución está en camino. De momento he cortado la pieza en tres, y ahora se acopla bastante bien al ténder. La solución final será sustituir una de esas piezas por una nueva casera hecha con gravilla de la que se usa para simular el balasto.

En el primer caso, la modificación consistía en incluir un fuego de hogar en el cuerpo principal de la locomotora; instalar un fumígeno y reparar los desperfectos que el ténder trasero sufrió al hacer los agujeros para las luces. 

Lo más sencillo fue la instalación del fumígeno. La máquina disponía de un viejo fumígeno que no había podido probar por falta de aceite para quemar.  Justo cuando me disponía a instalar uno nuevo, el viejo comenzó a funcionar… y con unos pocos ajustes parece que he logrado que lance la cantidad justa de humo – en combinación con el sonido, el efecto es muy realista.

Para el desaguisado del ténder había poco que hacer. Con pasta de modalismo intenté reparar el daño, pintándolo luego lo mejor que pude. Como difusores de luz utilicé un trozo de metacrilato y silicona. Con un trozo de cartón conseguí que la luz no se escapara por ninún sitio. El resultado no es todo lo bueno que quería: los desperfectos son visibles – lección aprendida… “hay que ir con extremo cuidado al hacer agujeros en plástico”-;  y no se ve demasiada luz. Por un momento pensé en sustituir la bombilla que utilizo en el tender trasero por un par de leds… pero claro, la diferencia de luz entre la parte delantera y trasera sería notable.

La instalación del fuego me llevó más tiempo. Primero probé la instalación por la parte exterior de la carcasa de la locomotora, dejando a la vista dos cables rígidos. Para ello, soldé un pequeño led smd directamente a los cables, y éstos los conecté a la placa de conexiones en el tender. El problema era que los cables eran demsaiado visibles y dificultaban el giro del grupo locomotora-ténder.   

Al final me lié la manta a la cabeza e hice un pequeño agujero con ayuda de la dremel al cuerpo metálico de la locomotora. Aprovechando que me metía en faena, pinté y decoré un poco la cabina, siguiendo el ejemplo de un compañero de LCTM.

 El mayor problema vino porque en algún momento durante la anterior instalación, el decoder sufrió daño en la salida que controlaba el fuego… tardé un poco de tiempo en darme cuenta. No me ha quedado otra que poner un decoder nuevo y dejar el viejo para alguna digitalización que no necesite tantas funciones.

Pasando el led por la parte de dentro, el resultado es muy bueno… ya sólo falta colocar un maquinista.

La digitalización se plantaba como algo fácil, con mucho espacio para instalar los diferentes elementos y sin muchas dudas sobre lo que quería hacer:

- Incluir luces (LEDs) rojas y blancas para indicar el sentido de la marcha

- Incluir una luz en la sala de máquinas (función auxiliar 1).

- Usar la segunda función auxilair para controlar las luces rojas y poder apagarlas y encenderlas en función de si la locomotora circula sola o arrastrando un convoy.

A efectos prácticos esto conllevaba hacer una pequeña placa para las conexiones y el pequeño circuito de control de las luces rojas. Por supuesto también era necesaria la transformación del motor con el correspondiente imán.

La placa para el circuito era extremadamente sencilla y la verdad es que cuando la terminé estaba convencido de que se trataba de uno de las placas que mejor me habían quedado: bien definidas las pistas, bien cortado, quemada, acoplaba bien en la base de la loco,… Y fue justo entonces cuando las cosas se empezaron a torcer.

En primer lugar en la fase de soldado demostré todo mi mal pulso, dando como resultado un montón de excesos de estaño, cables despuntados y plástico quemado que hicieron desaparecer las pistas bien definidas para dar paso a los cortocircuitos. En una primera prueba la loco ni siquiera se movió… de encender los leds mejor no hablar. Cuando tras casi un día de limpieza conseguí encontrar y limpiar todos los cortos en la placa, la loco se movía… pero uno de los leds me seguía dando un corto… perdí otro día volviéndome loco con la “placa maldita”, soldando una y otra vez todo… hasta que me di cuenta que los leds empotrados en una de las cabeceras habían roto la funda termoretráctil entrando en contacto con el chasis: imposible de ver o encontrar, pues siempre tengo la precaución de cubrir con cinta aislante todos los puntos del chasis que pueden estar en contacto con la circuitería…. A estas alturas mi desesperación era extrema.

En fin, cuando ya todo parecía funcionar, al darle un poco de vida al motor un molestísimo parpadeo en los LEDs “apagados” me hizo reconsiderar por completo el diseño de la placa y su circuito.

He de decir que el circuito se basaba en uno de tantos que sirven para usar transistores como interruptores. Como mis clases de electrónica básica quedan un poco lejos, hasta le pedí a un compañero electrónico que repasara el circuito… y había estado funcionando en una placa de pruebas durante casi un mes… pero claro sin un motor cerca. En otras circunstancias hubiese empleado algo de tiempo en intentar comprender a que se debía el flickering e intentar solucionarlo, pero con los días que ya había perdido y lo sucia que había quedado la placa original… mi confianza en encontrar rápido el problema era nula.

Además, con tanto trasiego el conector NEM del decoder había pasado a mejor vida, sin conector “macho” no tenía ya sentido poner un conector “hembra” y para evitar udddas durante las pruebas había conectado directamente el decoder a las tomas de corriente y al motor – con su correspondiente inductancia. Así que me decidí por una placa mucho más ligera, para lo que diseñé n circuito completamente made in Manolo con los componentes que tenía por casa: un par de optoacopladores que compré hace tiempo para pruebas y, en principio, nunca iban a ser utilizados en ningún otro proyecto (no son los mismos que utilizo para el decoder de accesorios ni los que usaré para la placa del driver ORM).

El resultado, como se puede ver, algo mucho más ligero que básicamente pasa a ser una placa de conexiones para los distintos leds.

Y algunas fotos de la máquina montada (la fotografía no es lo mío).

A falta de terminar mi booster casero, los detectores infrarrojos y de hacer más copias de mi decoder de accesorios; me he puesto a construir la rampa de acceso a la estación subterránea. Además he incluido las modificaciones al diseño que ya presenté en un artículo anterior.

Tras dar inclinación a las vías, me ha parecido que era hora de clavarlas, y evitar así que se vicien y adquieran deformaciones. Para ello además de la capa de chapa de madera sobre la que se sujetan, he provisto el trazado de una cama de corcho que amortigua y da homogeneidad al recorrido.

Finalmente he pasado todos los cables ya a la cara inferior, dejando despejado el nivel de las vías.

La segunda gran novedad ha sido la inclusión del ordenador que correrá rocrail para controlar la maqueta.

Lo he instalado junto a la rampa, en una zona muy despejada de vías y cercana a los enchufes de la casa. Para albergarlo lo he alojado en una pequeña caja de metacrilato. En realidad, no se pude considerar una caja ya que, a fin de poder acceder a él y manipularlo desde abajo (cuando la maqueta esté terminada el acceso desde arriba será imposible), lo que he hecho ha sido fabricar tres paredes de metacrilado (arriba, abajo e izquierda) que se puedes desmontar para liberar el ordenador. La ventilación se garantiza por una de las paredes y con la inclusión de ventiladores. En la zona de ventilación se incluirá también el booster principal.