JOURNAL  (very long)    go to journal (II)  go to journal (III) 

most important links


  • We have been invited by Dr. Eric Wang to participate in the H.A.L.E. contest. The challenge consists of designing a payload for a meteorological balloon that will be launched to the stratosphere at an altitude of 27-34km. The purpose is to either carry along a camera or a device for scientific experiments.

  • We choose meteorological experiments.

  • At this point, the team is composed of Claude Baumann, Francis Massen and a group of LEGO robotics experienced students.

  • Our ideas now have been refined and we will come along with the following draft project:


    1. device-name: “LUXPAK”
    2. weight: less than 1kg
    3. package:
      1. size: should not exceed  40cm*20cm*20cm
      2. outer box : polystyrene (Styrodur) with reflective wrapping for thermal insulation
      3. inner box : plastic (undefined yet), contains all electronics parts
      4. inner box will be fixed to outer one with a shock absorbing structure made of LEGO pieces
    4. purpose:
      1. measure ozone-concentration, air-pressure, temperature (inside/outside), reflected light from earth during the ascension from ground to stratosphere, optionally also radioactivity
      2. obtain a vertical profile of the listed parameters
      3. in the case of a cloudless sky, the reflected light measurements could be used with ground-based data (that we might obtain from you after the experiment) to estimate the local albedo
    5. main processing and datalogging unit: RCX (We think that for the occasion of the Mindstorms anniversary it would be great to have at least one advanced RCX application. We also want to show that with astute engineering, “old” technology can solve modern problems quite well.)
      1. to prevent data from accidentally being lost from RCX-RAM, we will try to add a flash-memory board that regularly dumps the RCX-memory via the infrared channel.
      2. the flash-memory board will be able to switch on the RCX through a wire that is soldered in parallel to the RCX On/Off button (cf.  -we use a phototransistor there).
      3. optionally it also will be capable of installing the firmware to the RCX using the software technology that we developed for the RCX virus, that you were the first to see in Austin during the 2005 conference
      4. The RCX firmware will be written in “Ultimate Robolab” (” ) and can be transferred –if necessary- to the RCX by any firmware downloader such as the original ROBOLAB software. NOTE: although ULTIMATE ROBOLAB runs with some difficulty under ROBOLAB29, we prefer ROBOLAB254 for which the software has been designed. It's the best environment choice.
    6. power supply : 12V battery pack; heat dissipation through down-regulations will be used to heat some sensors and compensate temperature losses
    7. sensors:
      1. RCX needs sensor multiplexer:
  • · this device will work in combination with the flash-memory board

  • · transmission of the data to the RCX via infrared channel

  • · PIC16F88 microcontroller-based

  • · programmed with “Ultimate Robolab for PICs” (see above link)

      1. ozone:
  • · A-21ZX from ECO-Sensors ( )

  • · available from meteoLCD

  • · air will be led to the sensor through a tubing system with the help of a LEGO-made air-pump

  • · on the way to the sensor the air will be possibly heated up to the ambient temperature of the inner box

  • · the A-21ZX has no available output port; it therefore is hacked to the analog sensor line that enters the internal microcontroller

  • · output voltage 0..2V

  • · the sensor has an own battery system that will be fully charged at start; however, to maintain the voltage, the device is also connected to the main supply

  • · if being charged, the sensor needs about 40mA at 12V

      1. air-pressure:
  • · SCX15AN from Sensor Technics ( )

  • · available from meteoLCD

  • · absolute pressure sensor that covers the range from 0..1200hP

  • · will be manually calibrated before implementation

  • · sensor is extended with an OpAmp circuit to have an output voltage of 0..2V

  • · sensor consumes about 15mA at 12V

      1. air-temperature (outside) :
  • · PT100

  • · available from meteoLCD

  • · extended with an OpAmp circuit that acts as a constant current source

  • · output voltage 0..2V

  • · sensor consumes 12mA at 12V

      1. temperature (inside) :
  • · standard LEGO temperature sensor

      1. back scattered light sensor :
  • · Vintage ESR SI-diode sensor from Delta-T (

  • · available from meteoLCD, calibrated against a CM-21 pyranometer from Kipp & Zonen

  • · some more detailed information is still missing

      1. optionally : autonomous Geiger-counter datalogger
  • · Gamma-Scout ( )

  • · fully autonomous from the rest of the system

  • · measures the dose rate in microSv/h or counts in Bq; measures beta + gamma

    1. operation: a single switch will start all sensors and the logging/command  procedures of the NXT computer. It is assumed that the payload (of which LUXPAK is one component) will be brought back safe by a parachute, so the equipment should survive a rough landing
University of Nevada High Altitude Ballooning
Luxembourg meteo station (LCD)


  • Francis successfully hacked the A-21ZX O3 sensor in order to find an analog signal output, and he made a few calibration tests:

  • A small connector leads the analog line out of the box. A question reamains: how will the device be switched on/off?

A-21ZX product manual


  • Claude succeeded in activating a standard SD-card in SPI mode with a PIC16F819 (the little brother of 16F88) :

(little error on th picture: 16F819 instead of the indicated 16F84)

  • The PIC is programmed to wake up the card in SPI mode (send a series of 0xFF with /CS=HIGH) and send a command 0x40 0x00 0x00 0x95 that should return a result 0x1. (If the transaction succeeds, the LED will flash slowly. In the other case, it will blink quickly. Here the Ultimate ROBOLAB for PICs program: ATTENTION (added April 12th): two vis have been inverted !!!

  • NOTE that you must manually change one of the SSP configuration lines to BCF SSPSTAT,CKE before assembling:

  • Obviously there is a mistake in the first equation of the 7-bit cyclic redundancy check (CRC7). It should be written: G(x)=x7+x3+1.

  • But, using the formulas, it is impossible to obtain the correct CRC. It seems that SD producers don't publish everything openly.

  • Example: CMD0 (GO_IDLE_STATE - reset the SD Card) : byte1 = 0x40; bytes 2-5 = 0; byte 6 = 0x95

    • G(x)=137, x=2

    • M(x)=64*2564=274877906944

    • CRC=(274877906944 * 128) mod 137 = 7

    • and byte 6 would equal 7*2+1=0xF

  • After some calculations, we found that there is only one way to obtain the correct 6th byte:

    • CRC[6..0] = Remainder [(M(x)*(x7)2)/G(x)], so the augmentation (that's the official name for this multiplication in this CRC calculation) must be done differently than indicated in the manual.

    • with this formula we get: CRC=(274877906944 * 1282) mod 137 = 4503599627370496 mod 137 = 74

    • and byte 6 equals 74*2+1=0x95

  • Fortunately the manual tells us that the CRC byte only is required for CMD0. The checking is disabled otherwise in SPI-mode.

SD-card documentation
writing and reading a MMC-Card with a PIC
Jean-Claude Feltes' AVR project with SD Card
Ultimate ROBOLAB for PICs
Interfacing SD Cards
SD Card storage
CRC algorithms
Sd Karten Spezifikation
Anbindung an SD Karten


  • Yannick Zanella, our cook, phoned a lot in order to get one of those freezing boxes made of hard polystyrene. Thanks, Yannick!

  • We will have to cut down that box, because he was only able to find 40x40xN cm3 (N=16.5; 24; 40) The one we now have is 40x40x24. Cutting it will make it 40x20x24.

  • LabVIEW allows building graphical sub-modules. Now the SD_card control program also sends CMD1 and waits until the card is in ready state or a timeout occurred:




  • Jean Mootz has joined the team. Cool ! A few greatful words about this most exceptional person have been expressed by ETH Professor Dr. François Diederich, ... the very best of the long list of scientists, engineers and pedagogues who have enjoyed Jean Mootz in class.

    • He is going to realize the electronics for the PT100 and the special light sensor. (Output 0..2V, supply 12V)



  • Francis will investigate the loss of temperature with a 11 grad high school class (IIIe), while treating the theme of the thermical conduction. We will abandon the idea of the thermic insulating wrapping. The polystyrene case normally will be sufficient.

  • Francis also has weighted two sensors:

    • Mass Gamma-Scout = 150g

    • Mass O3 sensor =   134g




  • Francis has worked on the air heating system:

    • He uses 2 AA 1V5 separate batteries (2800mAh) with 2 big resistors of 1Ohm. The silicon tube (48cm) is wrapped around the resistors.

    • After switching on, because of the thermical inertia, nothing noticeable happens

    • Then, after a while, the heat concentrates and increases in the isolating material as the outer temperature falls.

    • Neither the Si-tube nor the isolating material doesn't melt or burn.

    • The batteries will keep working for 2 hours, enough for the task.

  • Eric Wang says:

    • That we can expect the balloon to ascend at about 1000-1200 feet per minute. It's expected to reach between 85000 to 105000 feet.

    • The altitude is based on GPS and is data logged for the entire mission automatically once per second by an onboard system and its also recoded by the ground station once every 30 seconds.

    • The full mission data from all the payloads will be made available to everyone after the mission.



  • We will abandon the SD Card idea, because by no means we were able to write or read data to the card. We guess that there is essential information that is not available on the web about data token, error handling and so on. Or we are doing something completely wrong. But, we didn't find the bug. :-(

  • Instead Claude is playing with a serial I2C EEPROM that can be connected to a PIC much more easily. We intend to use the 16F88 that has an SSP-module. Unfortunately this is not sufficient to assure hardware master I2C (an MSSP would be required.) But it's rather an easy thing to set up a bit-banged protocol.

  • We will follow Sprut's idea in order to have 2 "open-drain" driver-lines. He suggests using 4 pins, separating output and input signals through diodes. This is quite an generous use of rare pins, but the advantege is that the ports must not constantly toggle between output and input functions, and that much higher currents can be sunk.

  • The diodes also give the possibility to verify the presence of the acknowledgment bit very easily.

  • Using his code inside an Ultimate Robolab for PICs program with a test 24C08B EEPROM, we are able to obtain the acknowledgment (ACK) pulse from the EEPROM, when sending the control byte b'10100000'. We also are able to write and read a byte to the EEPROM.

  • The following pictures show oscillograph pictures of repeated control byte sending and the RX of the ACK bit (pulling down the SDA line)

    diode blocked SDA signal

SDA signal with ACK

  • The start condition can be recognized (HIGH to LOW transistion), then the bits b'10100000', the ACK bit and the final stop-bit.

  • Here the sending of the control byte and the data address 0x03, followed by the stop bit:

  • Note that Sprut has masked the wait for ACK as comment in the i2c_tx routine. If the ACK does not appear, the program could hang up here. Thus, a timeout function needs to be added either through the watchdog timer, another timer or a simple counter.

  • The following shot shows the sequence of reading the value 0x05 (b'00000101') from memory address 0x03 (b'00000011'). The reading sequence is:

    1. send start bit

    2. send write-control-byte 0xA0 (b'10100000')

    3. wait for ACK

    4. send address 0x03 (NOTE that 24C08B only needs one address byte, the page address is given by the 3 lower bits of the control byte)

    5. wait for ACK

    6. send stop bit

    7. send start bit

    8. send read-control-byte 0xA1 (b'10100001')

    9. wait for ACK

    10. read byte (no master ACK)

    11. send stop bit

Bit-banged I2C master connection
Usage of Microchip I2C serial EEPROM
Software implementation of an I2C master bus
Interfacing I2C serial EEPROM to PIC microcontrollers


  • First tests with the air pump:

    • we want to use the LEGO red micromotor (Part. 2986) that according to Philo has a stalled torque of, a stalled current of 80mA, no-load current 6mA, produces at 9V 16rpm, with 21mW mechanical power at an efficiency of 16% (current 40mA). This motor has a few advantages for this purpose:

      • weight: 10g

      • small size

      • low current (especially the stalled current; if ever the piston will be frozen, the current won't empty the batteries.)

    • Using a single piston, this motor is able to move about 5cm^3/minute, which is sufficient for the O3-sensor.

    • The piston system needs to be placed inside of an air-proof box that has an inlet and an outlet.

  • Although Sprut's I2C code succesfully sends bytes to the 24C08B EEPROM, and also receives the correct RX-message, the I2C_RX routine (RdI2cW-subroutine) has a serious bug, that he probably does not notice, because he is using 16F628 Schmitt-Trigger inputs. Since we are going to work with the 16F88 that only has TTL inputs, the bug badly affects the RX. In fact, with the original code it is not possible to extract the byte from the signal (the code between ;++++++ is the RdI2cW-code):

  • The routine reads the data-bit BEFORE the clock goes HIGH, which is wrong according to the I2C specifications. The data is only valid during the clock HIGH state. We must change the code to:     

  • ;+++++++++++++++++++++++++++++++++++
         clrf buf 
         movlw 8 
         movwf cntbt 
         bsf SDAo ;failsave 
         bsf SCL ; Takt high 
         btfss SCLi 
         goto RdI2cW2 
         btfsc SDAi 
         rlf buf,f 
         bcf SCL ; Takt low 
         decfsz cntbt,f ; 8 Bits drinn? 
         goto RdI2cW1 ; nein 
         movfw buf ; ja fertig 

LEGO pneumatics review
Air muscle (for the gallery !!)
Philo's LEGO motor page


  • We definitely abandoned Sprut's code. Although TX works without fail, RX produces many data errors. One issue could be the capacitance of the diodes.

  • ==> we switched to Microchip's source code. They are using the meanwhile illegal instruction TRIS, that we must replace with a sequence:

    • bank1
      movwf TRISB

  • The Microchip author sets the dataline HIGH by switching the pin to input mode. We changed the code in that way that in the beginning of the TX routine, the SDA-line is set to output. Then the bits are sent by pulling the pin high or low. When reading the ACK-bit, the pin is changed to input. ATTENTION: switching to output internally sets the pin in LOW state, which produces bad readings on the device side. Therefore we first set the pin HIGH, as if it already was configured as output. Then we toggle the mode to input, and the pin remains HIGH:

    • bsf PORTB,SDA ; Pull SDA high 
      movlw SDA_OUT ; Configure SDA to be an output
      movwf TRISB ; Copy value to TRISB register

  • We also add a few NOPs to improve the timing

  • The software now produces an error (i2c_error=1), if the ACK is not received from the device.

  • Download URP (ULTIMATE ROBOLAB for PICs) code for sending ( and reading (

  • In this library you also will find (see below), that first writes 255 bytes to the EEPROM, then reads them out and sends them over the serial UART channel. (Note that the 16F88 is not pin compatible with the 16F628 for the UART.)

  • We connected a LDR light resistor to 16F88 PortA<2> -pulled up through a 10k resistor-. Then we added the ADC device to the firmware configuration and sampled during 60 minutes. (We used a pocket light to produce changing light intensity.) After this sampling time the data is sent via UART to the PC:

  • Here a next test: the charging curve a 1600uF capacitor through a 10k resistor. The purpose of this test was to verify if higher address locations are written and read as well. The main 255-loop was placed inside of another 50-loop.

  • This confirms that we are able to use I2C, UART and ADC without fail on the 16F88.

  • Here the breadboard for the capacitor experiment.

  • Now we started playing with the pressure sensor. Connecting the sensor-board (sensor plus op-amp circuit) to the experimental logger with a LEGO piston and tubing that allows some controlled pressure steps. The voltage is obtained by adding a 10k pull-up resistor to the PIC input port and connecting the sensor-board output to the logger ground and the sensor-board ground via 100k to the PIC. The sensor negative voltage (compared to the PIC-board) REDUCES the PIC ADC voltage, as the pressure increases. Note that we added a 1k resistor between the 10k/100k bridge and the PIC input in order to prevent accidental high current.

  • Note that with the internal oscillator being used in the PIC, there are 8 analog input ports available. (2 of them may be configured as reference voltages.)

Francis suggests a very simple and astute solution for the air transport. The deduced necessary heating power is described in the Excel-sheet. The calculations estimate the heating in function of the flight altitude:

adiabatic atmosphere


  • It's time to distribute the tasks between the RCX and the datalogger board. Here a few discussable ideas.

    RCX :

    • Sensor1 : measure the temperature inside of the electronics box (original LEGO temperature sensor range -20° ... 50°)

    • Sensor2 : measure the temperature around the air tubing (original LEGO thermometer or thermistor; Mike Gasperi's temperature sensor)

    • Sensor3 : not sure yet

    • Battery level : measure the power supply for the RCX.

    • Output1 : produce heat ==> if the box temperature drops below a certain value (RCX output ports certainly support constant 100mA through a load producing 9*100=900mW heat in the case of a pure resistive load)

    • Output2 : produce heat around the tubing

    • Output3 : not sure yet

    • On/Off button hack : we first thought that we could do the job without any hardware hack. But, the issue is that we will send LUXPAK to Eric Wang, who will have to start the system manually in Nevada. We cannot expect that Eric will press 5 different power buttons and follow a complicated check-list before launch. We will install one only outer button that turns on the whole system. The datalogger will then switch on the RCX (as described in our most recent Mars project).

    Datalogger :

    • at system start : switch on the RCX and other devices

    • install the firmware on the RCX via infrared (get the firmware from EEPROM)

    • allow the storage of the RCX firmware in EEPROM

    • collect the data from other devices (O3...)

    • receive temperature, battery and heater switching data from RCX

    • receive time stamp since launch from RCX

    • store all the data on the EEPROM

    • exterior LED indicators that prove that everything is working fine



  • Now the datalogger prototype (let's call it PICLOG) is able to send from RAM, receive, store to RAM and verify the integrity of RCX infrared packets.

  • Packet form :

    • header : 55 FF 00

    • opcode : 1 byte + complement byte

    • parameters : N bytes + N complements

    • checksum : 1 byte + complement

  • Note that the RCX needs the 9th parity bit (odd), while the PC-tower doesn't require it.

  • Maximum packet size : N = 94 bytes

  • Before sending a packet, software must add the checksum

  • Packets are stored in RAM (or later in EEPROM) in the form:

    • opcode : 1 byte

    • parameters : N bytes

    • checksum : 1 byte

      • (The reason for also saving the checksum is a small gain of speed and memory. Later the PC will send the RCX firmware to PICLOG through the normal RCX download procedure. Thus the packets will already contain the correct checksum. The firmware packets also will contain the block data, the block checksums and the firmware, which must not be calculated again. Note however that firmware packets will not have the normal 200 payload bytes size)

  • The sending is done through a back-to-back machine. The 16F88 UART generates an interrupt, if the hardware buffer has been emptied. The interrupt service routine then sends the next byte to the hardware buffer until the last byte has been sent. This mechanism does not generate any transmisison error, because the next byte is only moved from RAM to the hardware buffer, if the buffer is free.

  • However it might happen that the RX interrupt handling is slower than the arriving byte rate due to other interrupt handling for example. This would produce a RX hardware buffer overrun. The infrared channel also could capture bad packets (missing bytes, for instance). This will be detected by the packet integrity tests.

  • Note that software must clear th error states

  • If a VALID packet has been received and stored into RAM, the UART module will no longer store any byte to RAM. TX will also be prohibited. The software has to react to the packet and clear the VALID state.

  • The UART system only works in half duplex, because RX and TX use the same infrared channel.

  • The UART software module works as a state machine :

  • TODO: Note that the state machine could be blocked in RX-state, if the transmission was disrupted. In that case, a certain number of bytes would be necessary to generate an error state. Therefore the main software should verify, if the program remains in RX-state too long.

  • Now PICLOG will be programmed to correctly receive and store an RCX firmware to EEPROM.

    • Later, this will only be allowed, if a jumper is set, in order to prevent accidental erase of the RCX firmware

  • The following step will be the transmission of the firmware from EEPROM to the RCX.

Information on LEGO RCX protocol


  • Today's discussion with Francis, Jean-Claude Krack, who also joined the company and Claude. Main discussion points:

    • Isolating box

      • The one shown above definitely is too big. Either we cut it with a hot wire and glue it or we try to find a better sized one

      • Francis made a few tests in the freezer with a soft polystyrene box about 40x20x20cm; wall : 25mm:

        • After half an hour the inner temperature has reached 0° (at start the interior temperature was 23°; freezer temperature was -22°)

      • Jean-Claude carries along another model, white coloured 40x26x26cm, which might do the job; wall 3cm. He also proposes to ask his liquid air provider. Thanks Jean-Claude.

    • Heating:

      • The heating is one of the big issues.

      • Francis proposes a series of resistors with wholes through which the O3-tube will be led in order to heat the incoming air. Here a shot of the resistor-net:

      • Claude proposes to make of the RCX an intelligent heating device that will control the heating of the electronics and the tubing.

    • Isolation for the electronics and tubing will be done by non-inflammable isolating material

    • Batteries: Francis is looking for the best possible model.

    • Jean Mootz already finished the constant current supply for the PTR100 with ap-amps also for the light sensor. Thanks a lot.

  • PICLOG now is able to talk to an RCX or a PC through the LEGO tower. We also can "download" a LEGO RCX firmware to PICLOG. The firmware isn't stored to EEPROM yet, but all the bytes are well received and the replies are sent correctly. (The PICLOG does not understand the unlock command, which is not necessary anyway. This will cause an error-message. (We will add this reply only, if there remains enough memory space on the PIC.) There are only 2 things that must be changed in the PC downloader program:

    • Instead of using the standard 200 bytes payload for one 0x45 packet, we only allow 89 (=96-7). The 16F88 RX buffer is limited to 96 bytes by our software (bank2). The downloader adds 7 control bytes.

    • The last packet must be filled with zeros to have the same data-size



  • Francis weighted some more parts:

    • pressure sensor = 32g
      ozone sensor = 134g
      light sensor = 16g
      Mootz_board with Pt100 = 20g

  • He must add a terminating 10k resistor to the light sensor

  • Francis will repeat the cooling test in the freezer for Jean-Claude's box. It seems to be impossible to thermically stabilize an empty container. He therefore adds a bottle of 200ml water (c=4185) corresponding to about 800g of material with c estimated between 800 and 1200)

  • The resistor net now has 3 parallel blocks of two serial resistors. The temperature reaches 75° at 600mA current. (The RCX will not be able to provide this current directly, so one port will only be used to switch on an off a power transistor like the 2N3055.

  • Here a few shots of the selected and realized devices:

  • Datalogger used for measuring the thermical isolation of one our boxes:

  • That's the sensor head: (tiny compared to the permanent installation, isn't it?):

Temperature change in an insulated transport box
Without heat


  • Now PICLOG is able to receive an RCX firmware, store it in EEPROM memory and correctly answer all the replies to the ROBOLAB firmware download program. The only major change had to be done in the downloader. Instead of sending all the firmware packets to the internal serial, we send them one by one, adding a generous pause between each block to give PICLOG the time to store the bytes in EEPROM. As already said, the block-size is limited to 89 payload bytes (totally 96 bytes) and the last packet is filled up with zeros to have the same size.

  • Here a screen-shot of the PICLOG replies that have been sniffed from the serial communication. The last firmware block has been correctly received and is accepted with a B2 00 reply (0xB2 is the complement of 0xAD - the toggle bit is set in this packet). Then PICLOG replies with 5A "Just a bit off the block!" to the UnlockFirmware command 0xA5 (toggle bit cleared.) Note that the rest of the bytes are part of a debugging message that uploaded the contents of the UART RX buffer. Parts of the previous packet has been overwritten with the very last received packet A5 LEGO... and you can read the firmware terminating code "Do you byte, when I knock?". Also note the couples of yellow framed bytes which are dummy bytes sent by PICLOG software to the internal UART TX buffer, in order to keep the IR-carrier on oscillating during the transmission of the infrared packets. These dummy bytes are NOT sent by infrared, because at the moment the 16F88 UART module would empty its hardware TX buffers, the carrier is already shut off.

  • Uploaded our proposal document for participation in H.A.L.E.


  • Now PICLOG also is able to correctly send an RCX firmware that previously has been stored into EEPROM from PC via LEGO tower.

  • Here a few shots: 1. download to PIC from LEGO tower   2. download to RCX from PIC    3. RCX in download mode

  • Unfortunately the PIC programs to receive, store and send RCX firmwares occupy almost the whole PIC memory.

  • ==> we separate the projects into 3 devices :

    • an EEPROMer device that will allow to fill EEPROMs with RCX firmwares using the LEGO tower

    • an RCX bootloader that will switch on the RCX, detect the presence of the firmware and if not deteceted, send it to the RCX

    • PICLOG that will do all the datalogging while storing sensor data and received data from the RCX

  • The RCX will be the central unit:

    • we will use the specially prepared RCX with the small phototransistor able to be switch on and off by external devices

    • the bootloader will measure the sensor port voltage. If the voltage is zero, the bootloader (we will call it SNOOP_LOAD) will shortly and brightly flash a LED. The RCX is switched on. SNOOP_LOAD recognizes this through the presence of a voltage.

    • If the firmware (we'll call it HALE_fw) is there, it will switch on RCX PORT C that serves as the power supply for PICLOG. SNOOP_LOAD also checks this voltage. If it is present, then SNOOP_LOAD will go into sleep mode. (It regularly will wake up to control the state.)

    • If the firmware is not detected, then the download process is started.



  • First we thought that we could do the datalogging and bootloading in one device. Then we found that the bootloader needed two different devices: the bootloader (called so far SNOOP_LOAD) and the EEPROMer. And PICLOG would represent a third device.

  • But now we are certain,... because everything correctly works, that we definetely need only 2 electronics:

    • The EEPROMer needed to download a LEGO RCX firmware to the serial I2C EEPROM via LEGO tower

      • From now on we call this one SNOOP_BURN and we represent it by the icon

    • The datalogger and bootloader are combined in one device

      • We call it SNOOP_LOG and it's represented by

  • The microcontroller program of is easy to describe (see above). It needs to reply correctly to the following LEGO RCX opcodes:
    • 0x10 (PING)
    • 0x65 (RESET)
    • 0x75 (START FIRMWARE DOWNLOAD, also get the firmware checksum -SNOOP_BURN needs to store this to EEPROM address 0x7FFE (little endian) )
    • 0x45 (SEND FIRMWARE BLOCK): firmware blocks have a block number starting with 1. The last block has number 0. From the block number the SNOOP_BURN calculates the correct EEPROM address for the block. Each block has 96 bytes, corresponding to the maximum buffer size in one bank of the PIC 16F88. The block data is stored with the opcode and the checksum, but without the header and the complements. (This makes the sending procedure for SNOOP_LOG slightly easier.)
    • 0xA5 (ULNOCK FIRMWARE): SNOOP_BURN does not check the integrity of the firmware. But, since SNOOP_BURN verifies the transmission of every block, we are certain that it received the firmware without fail.
    • The program does not abort the download, if any error occurred. (This does never happen, since the only error that could compromise the procedure is the I2C ACK missing error. We are certain about the I2C channel, so why should something happen.). The data security comes from the ROBOLAB firmware download program, which surveys the integrity of the replies during the download. If a packet is not received, because an UART error occurred, the PC software simply resends the packet.
  • The only restrictions to normal the RCX firmware receive procedure are in relationship with the boot_loader:
    • 0x45 packets have the form:
      0x45 block_ID_LO block_ID_HI N_LO N_HI data[0] ... data[N-1] block-checksum checksum
      1t 2nd 3d (=0) 4th (=96) 5th (=0) data[0]   data[88] 6th 7th
    • ==> Each block can transport 89 payload bytes and has 7 packet information bytes.
  • The PC download software in ROBOLAB is changed from the ULTIMATE ROBOLAB "". the two major changes are:
    • The last remaining packet is filled up with dummy zeros in order to have 89 payload bytes
    • Each block is individually sent to SNOOP_BURN, because the EEPROM storing generates a 1 second delay to the normal reply.

  • The microcontroller program of obeys to the following flowchart:

  • The corresponding ULTIMATE ROBOLAB for PICs program looks like: (note the red Begin and End icons that include PL211 bug fixes and allow PIC16F88 to run all the ISR functions in program page 1, e.a. addresses 0x800+)

  • The bootloader part executes the flowchart below: (a pause is added at the end to give the RCX the chance to run the firmware)

  • Firmware checksum is NOT computed by the bootloader, but must have been stored by SNOOP_BURN at EEPROM address 0x7FFE little endian)

  • EEPROM hardware address is 0 ! It is not possible to accidentally overwrite the firmware EEPROM, because the hardware Write Protection (WP) pin is set.

  • The only EEPROM read error might be a missing ACK. This did never happen in the tests. Our I2C bit-banged master runs without fail. We could force this error, if the EEPROM enable pins are bad wired or either the clock or the data lines were unconnected.

  • RCX firmwares never exceed 20kB. If zero block_ID never appears, which only is the case, if no valid firmware was present on the EEPROM, the program needs to detect this.

  • From the RCX virus experiment, we know that firmware download works very reliably at 2400baud. Download rarely fails. Due to an RCX firmware bug, any block sending fail could hang up the firmware download, and the process has to be manually stopped. (This happens with any firmware downloader). But, if we don't check the RCX reply and have the RCX verify the firmware integrity after download through the firmware checksum, then there are many chances that the firmware has been correctly stored, even if a packet integrity issue happened during transmission. If the RCX does not accept the firmware, it sends an acoustical signal and resets its internal state. SNOOP_LOG can restart transmitting the firmware.

  • In the dark of LUXPAK interior the chances of IR disturbances are zero. Thus, we can expect that we have a 100% reliable IR-connection between SNOOP_LOG and the RCX.

  • If for any reason the firmware download could not work, there are two precautions:

    • The RCX firmware will be pre-installed on the RCX. We need to calculate the energy loss during a 2 weeks travel from Luxembourg to the launch place. We know the RCX consumes 34microA in software stand-by mode. The bootloading would then only be necessary, if the firmware had been accidently lost. (Due to energy economy this measure could be impossible ==> we have to think here.)

    • The RCX firmware -delivered as a .srec file- can be downloaded to the RCX through ROBOLAB manually. (Eric, this could be your job. If within 10 minutes the system does not work, this would be the option.)


  • The datalogging function of SNOOP_LOG works according to the following conventions:
    • The RCX is the intiator of any datalogging
    • The RCX firmware regularly sends a series of LASM SETV (opcode 0x14 (variable number, source, value_LO, value_HI) commands
      • variable 0 .. 4 SNOOP_LOG reads its analog channels 0..4 (note that channel 3 is the 2V reference voltage) and stores the values in RAM
      • variables 5 .. 31 SNOOP_LOG stores value_LO, value_HI that it received from the RCX into RAM at the address given through the variable number
    • If a whole record has been stored, the RCX sends out a message 0xF7 (1), which tells SNOOP_LOG to transfer the RAM to the next EEPROM slot.
      • EEPROM hardware address is 1
      • The RCX will run a clock that will provide a time stamp for each record.
      • If the EEPROM reaches the end of its capacity, no other data will be stored and the program generates a "memory full" error. The last 2 bytes are lost anyway, but the raw data analyzing software should ignore the very last record.
    • 0xF7 (2) may be sent to SNOOP_LOG later in order to extract the data from EEPROM. SNOOP_LOG will then stream the raw data through the serial channel to the PC (RS232). The IR-carrier will be shut off, and the data will not be sent on the IR-channel. PC software should extract the records from the raw data.
    • 0xF7 (dec57=0x39) resets the EEPROM HIMEM pointing to the next free address on EEPROM. Note that switching SNOOP_LOG off will not affect the EEPROM pointer. (The data pointer is localized on the PIC 16F88 internal EEPROM address 0x0 (little endian).
    • The RCX does not know, whether the current data received from SNOOP_LOG belongs to the same data record. (It was not possible to add any reply protocol or record integrity checking, because the PIC 16F88 run out of program memory.) But, if we make sure that enough time is paused between the RCX data sending, then SNOOP_LOG will have had the time to clear any UART error, which could be the only error source here.
  • SNOOP_LOG's schematics:




    • PIC16F88 is configured with internal oscillator at 8MHz. Thus no crystal is needed and Osc1 and Osc2 can be used as digital outputs. (Osc1 is not connected though.)

    • MCLR is configured as input by default in ULTIMATE ROBOLAB FOR PICS. To avoid floating input, the port is pulled up to Vcc

    • T1 and T2 form a logical AND-gate and they are driven in saturation. Therefore the infrared LED D6 will only be switched on, if both transistors are conducting. If a serial signal is transmitted over the infrared channel, the 38kHz carrier must be active. Since the TX line is HIGH by in the case of a SPACE, and LOW in the case of a MARK bit, T2 must be PNP.

    • The collector T3 can be connected directly to the RS232 RX line of a PC. The TX signals can be followed by a PC. This is particularly useful -besides the final data-upload- if debugging messages are being sent from the PIC via TX with carrier shut down. The normal infrared transmission will not be affected by the additional debigging messages.

    • D2, D4 and D5 are polarity protecting diodes only

    • In order to save energy, the red LED D8 is only switched on rarely, while the green LED D7 is constantly on (see below). The yellow LED D3 does not emit light, because of the 100k resistor. In series with D9 this LED is used to produce the constant reference voltage of 2V. (Note that the voltage drop through a LED does not depend on the current -at least not very much)  All visible light LEDs are low cuurent devices.

    • The resitor/diode bridge D1/D4/R2/R8 produces a valid TTL voltage for the PIC input RB7 from one of the RCX output 9V voltages. R8 is necessary to decouple the device ground from the floating ground of the RCX output bridge.

    • The serial EEPROM IC2 contains the RCX firmware. The chip's Write Protection (WP) is pulled up to avoid accidental overwriting. Device address A2A1A0 = 0.

    • The serial EEPROM IC3 is going to receive the logger data. WP is kept unconnected, internally tied LOW. Thus the EEPROM can be written to. The device address A2A1A0=1

    • All sub-circuits are decoupled through capacitors.


    • At start red LED D8 shortly flashes once to show SNOOP_LOG is running

    • If the RCX is ON and the RCX-firmware is correctly running, the green LED D7 is ON

    • If the RCX has successfully been switched on by the boot-loader function of SNOOP_LOG, the red LED will flash at each firmware-block that is transmitted to the RCX.

    • If any communication error happens, the red LED will rapidly flash a certain number of times, before slowly flashing a few times. The number of flashes corresponds to the error number (see: error messages below).

    • In datalogging mode, the red LED will shortly flash, if the data is transferred from PIC RAM to EEPROM.


  1. I2C ACK missing (should never happen)

  2. UART RX error (overrun, header, complement or checksum error -rarely happens, especially in the dark of LUXPAK's box)

  3. Block address error - attempt to write a firmware block beyond the allowed RCX limits (24000 bytes) -should not happen

  4. Data-logger full -should not happen


    • Note that yellow LED D3 and the small signal LED D9 replace a 2V Zener diode of an earlier version (that is no longer available here in order to avoid version conflicts.

    • The long green analog channel connector has the following order.(Note that if one analog input should be used unplugged, it should be grounded through a 100k resistor in order to avoid floating input effects. Alos note that the 2V reference voltage is high impedance, it cannot be used as a power supply.)

1 2 3 4 5 6 7 8 9 10

  • SNOOP_LOG in action with a hacked RCX. The breadboard on the left side holds an optocoupler that is used instead of the initial photo-transistor explained above.

  • In order do save one RCX input line, we solder a wire to the +V pin and the 0V pin of the IR receiver and we add an external 100nF decoupling capacitor. The +V pin always has 0V, if the RCX is switched off and +5V, if switched on. We therefore may use the pin as a hardware indicator of the RCX basic state. This voltage is not affected through IR-traffic. (cf. Mark Bellis' circuit description on the next picture.)

  • The flowchart from above changes to:


RCX IR Rx circuit


  • The first long-time test of our SNOOP_LOG prototype reveals a few things:

    • Switch on RCX never fails

    • However, passing into boot-mode sometimes fails. The reason is that PIC16F88 pin RB7 sometimes reads a TTL level HIGH although the RCX port C has not been switched on. When running the executive, the RCX output ports seem to be in float mode. At RB7 we measure 1V, which should produce TTL LOW. Probably there are some spurious peaks, because through the RCX float mode, the RB7 input encounters high impedance on the RCX counter-part. Therefore we add a 10k resistor in parallel to Zener diode D1.

    • The voltage between GND and -V of the RCX output is 0.3V. We therefore reduce R8 from 33k to 100R.

    • If the RCX is switched on before SNOOP_LOG (which should only happen during tests), RB6 reacts as an low impedance output with level LOW and a rather high current is shortly drawn until the SNOOP_LOG power-up. We therefore add a 10k resitor in series with blocking diode D5 in order to protect both the RCX and PIC16F88 from damage.

    • Firmware download to the RCX from SNOOP_LOG never fails.

    • In datalog mode, we sometimes get an UART error message, if two 0xF7 (1) messages succeed to rapidly. The reason is that this message causes SNOOP_LOG to store the data on EEPROM. In the actual version (_v23) the record length is 16 bytes. The EEPROM writing needs 8ms per byte (we added 3ms to the prescribed 5ms in order to avoid any write error.). Since the data pointer also is saved in EEPROM, two write cycles must be added. The RCX absolutely needs to respect a generous delay between two 0xF7 (1) messages to give SNOOP_LOG the time to reset the UART in RX-mode. Note that after a 0xF7 (2) message SNOOP_LOG is unable to receive for the duration of the data output stream.

  • What do we measure with SNOOP_LOG:

    • SNOOP_LOG analog inputs AN0/AN1/AN2/AN4. We do not need to read the reference voltage AN3, because the raw value always is 0x3FF. But it could be an excellent bad record indicator, in the case of a value that would differ from that value. ==> (5 words)

    • RCX values

      • time since start in seconds (1 word)

      • Sensor 1 & 2 (2 words) (for sensor 3 see below)

      • Output state A & B (2 words)

      • battery level (1 word)

      • termination word (0x0D 0x0A = end of line) to help the PC software to better analyze the raw data. (1 word) (If ever there was a spurious EEPROM write error, we'd detect it in a single record, without affecting the whole dataset.)

    • Total : 12 * 2 = 24 bytes

  • What timing can we expect:

    • The datalogging time is estimated to 2 hours ==> 32766 bytes /24/ 7200 ~=  0.20 records / 1s ~= 1 record/5s maximal EEPROM sampling rate

    • Each single sampling in RAM will be executed after an RCX 0x14 (p1, p2, p3, p4) command. The transmission of this command (15 bytes sent) needs 15*12/2400 =0.075 seconds. Remember that there are 8 bits + stop bit + start bit + parity bit = 11bits per byte. Add a small pause necessary to rearm the UART, let's say another 65ms... and you get a maximal RAM sampling rate of 7word/s

    • In order to keep the communication as much as possible error-free, we increase the timing, since there is no feed-back from SNOOP_LOG to the RCX : send 0x14 command every 0.5sec. After having sent the 12 successive 0x14 commands, send the 0xF1 (1) command telling SNOOP_LOG to transfer the data to the EEPROM. Wait 2 seconds after this command : realistic error-free record sampling rate : 1/8 = 0.125Hz = 7.5rec/min.  We expect an ascension speed of 5m/s, thus we sample once every 37.5m, which absolutely is acceptable.

    • ==> SNOOP_LOG program must be changed to accept 24 bytes instead of actual 16 !!!



  • Yesterday's meeting with Francis:

    • He has found a smaller black poystyrene box. Dimensions: 300x250x153 [mm]. Wall diameter: 29mm. The black corpus will absorb heat from the sun, but also the non-exposed surfaces will radiate the heat easily. However, since surely the ascension will impose a slow rotation to the box, an important surface will be expose to the sun. Suggestion: only paint in white colour the bottom of the box, that will never see direct sun light.

    • The box interior has the dimension: 242x192x95mm, sufficient for the complete LUXPAK modules.

    • The O3 sensor needs tubing that transports the air to the sensor head. Thermic isolation and heating is required.

    • O3 sensor's dimensions : 120x50x30mm

    • The weight list changes to:

      Polystyrene box


      Glass-wool 116g
      RCX 115g
      SNOOP_LOG 50g
      O3-sensor 134g
      Pressure sensor 36g
      Mootz-board with light sensor and PT100 80g
      Heating resistors (tube) 64g
      Box heating resistors and heating command 80g
      LEGO pieces 60g
      TOTAL 1035g
  • Conclusions:
    • We need the lightest possible NiMH battery pack !!!         ==> first estimate the needed energy
    • NiMH seem to have the best characteristics for this purpose although they present the serious issue of self-discharge
    • No inner box will be used
NiMH accus
  • The electronics need to be fixed to the inner box.
    • The glass-wool isolation will be glued to the box bottom
    • O3 sensor must be placed inside of a small box that also will be glued to one wall
    • For the battery, RCX and SNOOP_LOG, Erik and Laurent suggest:
      • Battery pack fixed with rubber belt (we use an old pack on the next picture that was disponible)
      • SNOOP_LOG PCboard clamped between LEGO brick and plates.
      • The pressure sensor should be fixed to the wall. (Not sure about this idea, because of the thermical conduction
    • Alessio proposes to use a solar panel to compensate the loss of electric power in the NiMH accus during the transportation from Luxembourg to Nevada


  • Questions about the heating:
    • How much heating will we need in the tubing? (see above)
    • What is changing, if we use a larger tube diameter?
    • How fast does the polystyrene box cool down?
    • If we add a heater inside of the box, how can w eprovide thermical conduction to the electronic devices?
      • convection at lower altitudes and high air pressure
      • radiation at higher altitudes and low air pressure (we know that vaccuum is an excellent thermical isolator, but our heaters won't radiate at low temperatures!!!)
      • Suggestions:
        • the RCX is powered with DC through the AC adapter plug. If the RCX consumes 100mA, this will produce a heating in the RCX rectifier bridge and voltage-regulator of (12-9)*0.1 = 0.3W. These parts are soldered on the RCX PCboard and thus thermical conduction is assured
        • SNOOP_LOG has low power consumption : ?????
        • Mootz_board: same issue
        • Pressure sensor : idem
        • battery pack : NiMH work best at high temperature. If we have enough current, the inner resistance will produce enough heat: ==> no problem
        • O3-sensor receives the heated air : ==> no problem
          • ==> Have the RCX directly supply the heating resistors (the higher current will increase the heat in the RCX electronics)
          • distribute box resistors: glue them to SNOOP_LOG and Mootz_board PCboards.
  • The box has a total surface of (0.3x0.25x2)+(0.3x0.153x2)+(0.25x0.153x2)=0.3183m^2
  • Filled with about 1kg of different materials, we obtain the following curve for the box in a freezer at -18° (ROBOLAB Investigator, RCX, LEGO temperature sensor):


Heating electronics
Electronics in the cold
a NASA issue
  • A picture of the optocoupler between SNOOP_LOG and the RCX (On/Off) button. The LED side is connected to SNOOP_LOG with a 220Ohm resistor. The photo-transistor side is wired to the On/Off button as shown in . No resistor is being used in this circuit, because the RCX already has a pull-up resistor.



  • We are not certain yet, how LUXPAK should be connected to the balloon. One possibility is a steel string that might be tied through the box. If this was the case, Laurent and Eric's design has to be changed a bit:

    • Note the blocking beams for the RCX wires that might loose through the transportation from Lux to Nevada

  • The RCX and SNOOP_LOG will be mounted vertically. The O3-sensor and pressure sensor boxes are glued to LEGO plates 1x4 and 1x5 respectively.

  • These plates are pressed into the lower beams fixing the sensors to the package.

  • Weight definetely is a problem. Therefore we took off the metal from the RCX bottom. The green box will receive Mootz_board later.

  • Inside the polystyrene box:

  • The isolation cylinder that will receive the tubing with the resistors must be cut to 45° in order to fit to the bottom of the box.

  • Practically the LEGO beams exactly have the size of the box inner height 95mm ==> fixing the whole LUXPAK device block to the box is very easy.

  • Important transformation:
    • Disposed as shown above, we loose 27% of the data records due to UART errors.
    • After a few tests, we found out that SNOOP_board's IR-receiver is placed too close to the RCX LEDs
    • ==> we rotate both the TSOP1738 and the IR-LED on the PCboard by 180° ;-( This is prototyping !!!!

  • Now SNOOP_LOG and RCX's IR-devices are distant by 10cm, and the communication is perfect at 100% again. (We will have long-term tests soon.) Anyway, LEGO recommends 10cm distance between the LEGO tower and the RCX. The reason probably is that the high-gain TSOP IR-decoder is too sensitive.




  • Francis is working on an overall report concerning the heating problem. He is studying the subject from a more theoretical point of view and verifies his calculations through experiments.

  • Battery options:

    • CONRAD Mignon "Endurance" article number 251020-62

      • 1.2V

      • AA

      • 2700mAh

      • <=18mOhm, very low self-discharge

      • 32g !!!

    • alternatively: Thomas Distributing: product number AP-E-4500-2

      • 1.2V

      • C

      • 4500mAh

      • low discharge

      • unfortunately no weight indication

  • We tested the SNOOP_LOG / RCX combination under the following conditions:

    • 40 data records (the first and the last record are lost - the first one, because the PIC ADC needs a few samplings, before it is able to do correct readings; why we loose the last one: no cue! SNOOP_LOG did not show any UART error, nor did we see any I2C error... bug somewhere?)

    • Sampling rate: 1 record / 8.5 seconds

    • apart the first and the last record, no further losses

    • O3-sensor plugged to AN0 (we produced weak electric arcs to generate some ozone)

    • pressure sensor to AN1 (added a piston ==> produced low pressure)

    • AN2, AN4 unplugged (floating)

    • RCX Sensor1: CdS light sensor

    • RCX Sensor2: potentiometer

    • at start RCX has no firmware, RCX is off

  • RCX Firmware "sn1.srec" on EEPROM, generated from original ULTIMATE ROBOLAB code:

  • As soon as SNOOP_LOG is powered, the RCX automatically switches on and the firmware is downloaded from SNOOP_LOG.

  • This takes about 4 minutes. The RCX plays the normal fast sweep system sound to confirm the correctness of the firmware. The display shows "SN1"

  • After a few seconds the data-transfer starts. No UART error, no I2C error, no other error.

  • The data upload is done after the whole sampling process by manually pressing the RCX PRGM button. The RCX sends a message 0xF7 (2) to SNOOP_LOG and the data is streamed out over the RS232 channel (no IR).

    • From the transmitted RCX time, we see that no record is missing: (except the last one! Remember that the first one has been manually erased.)

  • O3-raw values: slightly increasing due to the few weak electric arcs

  • The pressure decreases rapidly through the action of the piston. After a while the piston is released.

  • Unconnected floating inputs should be avoided. They must be grounded.

  • LEGO RCX sensor1 : a CdS light sensor receives changing light intensity.


  • LEGO RCX sensor2: a potentiometer is rotated slowly in both directions.

  • RCX battery level (AC adapter).

  • Undecoded data:


    • 1300 2A03 0D01 FF03 4100 2C04 7900 0200 04FF 04FF 6126 0D0A

    • 1300 2A03 6A01 FF03 8B00 5907 2D00 0400 04FF 04FF 7726 0D0A

    • 1400 2A03 DE00 FF03 7000 860A 3000 0200 04FF 04FF 7326 0D0A

    • 1500 2B03 2B01 FF03 3000 B30D E400 0700 04FF 04FF 6C26 0D0A

    • 1500 2A03 5A01 FF03 8800 E010 E100 E500 04FF 04FF 7626 0D0A

    • 1600 2A03 EC00 FF03 7400 0D14 E200 BC01 04FF 04FF 6B26 0D0A

    • 1600 2B03 1E01 FF03 2C00 3A17 E400 1B02 04FF 04FF 5A26 0D0A

    • 1600 2A03 5201 FF03 8C00 671A E200 8F02 04FF 04FF 7026 0D0A

    • 1600 2A03 D200 FF03 2A00 941D E100 B202 04FF 04FF 5426 0D0A

    • 1700 2B03 5B01 FF03 5C00 C120 E200 CC02 04FF 04FF 8826 0D0A 

    • 1700 2A03 0A01 FF03 8700 EE23 E200 F002 04FF 04FF 7526 0D0A

    • 1700 2B03 EC00 FF03 2000 1B27 E100 EF02 04FF 04FF 5B26 0D0A

    • 1800 CE01 5101 FF03 8300 482A E100 EF02 04FF 04FF 5626 0D0A

    • 1800 D801 0001 FF03 1C00 752D E200 EF02 04FF 04FF 7226 0D0A

    • 1800 CA01 5401 FF03 8300 A230 E000 F002 04FF 04FF 6926 0D0A

    • 1800 CC01 EC00 FF03 2200 CF33 A700 0003 04FF 04FF 6C26 0D0A

    • 1800 CD01 6001 FF03 6400 FC36 3901 2A03 04FF 04FF 6E26 0D0A

    • 1700 CE01 CE00 FF03 3B00 293A 9E03 2C03 04FF 04FF 8A26 0D0A

    • 1700 D001 6A01 FF03 7800 563D 9F03 2803 04FF 04FF 7026 0D0A

    • 1700 D001 DB00 FF03 6300 8340 DC00 2A03 04FF 04FF 6B26 0D0A

    • 1700 D101 4401 FF03 3700 B043 4B01 3303 04FF 04FF 6126 0D0A

    • 1600 D101 1801 FF03 8400 DD46 AD03 FD02 04FF 04FF 7226 0D0A

    • 1700 D201 F500 FF03 1700 0A4A 3501 FC02 04FF 04FF 7626 0D0A

    • 1700 D801 4601 FF03 7D00 374D 3501 FE02 04FF 04FF 6C26 0D0A

    • 1800 3D02 E300 FF03 1A00 6450 3201 FD02 04FF 04FF 6226 0D0A

    • 1800 3D02 5901 FF03 8400 9153 3301 CC02 04FF 04FF 6726 0D0A

    • 1800 3D02 EF00 FF03 1400 BE56 A601 CC02 04FF 04FF 6426 0D0A

    • 1800 3D02 5601 FF03 8600 EB59 0801 CC02 04FF 04FF 8026 0D0A

    • 1800 4002 1401 FF03 1E00 185D BF00 CB02 04FF 04FF 6426 0D0A

    • 1800 3D02 4001 FF03 8C00 4560 9E00 CB02 04FF 04FF 7626 0D0A

    • 1800 8002 2001 FF03 1C00 7263 A201 CC02 04FF 04FF 7626 0D0A

    • 1800 4A03 4201 FF03 8800 9F66 A101 CB02 04FF 04FF 6526 0D0A

    • 1800 2C03 2E01 FF03 3400 CC69 A801 CB02 04FF 04FF 7326 0D0A

    • 1800 2C03 1D01 FF03 8900 F96C A901 CC02 04FF 04FF 7C26 0D0A

    • 1800 2C03 4201 FF03 2800 2670 2D00 2002 04FF 04FF 6C26 0D0A

    • 1800 2C03 2F01 FF03 7E00 5373 7801 2202 04FF 04FF 6426 0D0A

    • 1800 2C03 0D01 FF03 1E00 8076 7A01 2002 04FF 04FF 7D26 0D0A

    • 1800 2C03 5C01 FF03 7800 AD79 7701 2002 04FF 04FF 7D26 0D0A

    • 1900 2C03 E200 FF03 4600 DA7C 7901 2102 04FF 04FF 6926 0D0A



  • Francis was very busy to realize his report about the heating problem. The theoretical consideration match well with the experiments.
  • Francis estimates the heat loss to about 3W, considering the outside temperature -44°C and the internal container temperature 0°C.
  • He concludes that no other heating than the ozone heater is necessary.
  • Questions:
    • In that case, can the heating be done by the RCX without additional electronics?
    • Philo assures that the RCX supports the requirements:
      • Main fuse 1.5A
      • Each RCX output port can drain 250-300mA without any trouble. The driver temperature protection switches off the output at about 500mA.
  • ==> best idea then is to distribute the heating resistors among both RCX outputs A and B.
  • other question: if the resistors are placed inside the isolating material, then the heat will probably not reach the rest of the container.
  • finally: if the balloon cable passes through the container through a tube, this tube MUST be isolated. So, we can use the isolation material here.
RCX output driver
report about the heating problem
  • SNOOP_BURN will not be part of LUXPAK, but it is needed to store the RCX firmware on serial EEPROM in the desired form.

  • We still have to solve the problem of the manipulations at start:
    • LUXPAK needs to be switched on 1 hour before launch, because of the warm-up time of the sensors.
    • The idea is to program the RCX to manage the data sampling at the tested rate 7 records/min. In that case, with record size being 24 bytes, the maximal datalogging time is 32765/24/7=195 minutes
    • Datalogging has been programmed in a way that accidental erase of the EEPROM is impossible.
    • Normally this should be sufficient: 1 hour before launch plus 2 hours flight
    • But, if any troubleshooting delays the launch, there should be a reset procedure.
    • The alternative could be something like that only starts the datalogging.


document concerning the heating problem
  • First temperature regulation tests with the RCX:
    • Test board:
      • RCX with three 10Ohm resistors in series connected to port A. (2 of them are 5W types, 1 is 3W type -in fact 12Ohm this one)
      • LEGO temperature sensor fixed to one of the resistors as shown on picture below. Added thermal grease between resistor and sensor.
      • ==> voltage at port A is 9V and current: 9/30=300mA; heating power: 9*0.3 =2.7W
      • control program should try to maintain the temperature at 40°C by reducing or increasing the output power.
      • easy control through slowly increasing or decreasing the output power (no PID)
      • the reaction of the system is expected to be slow
      • experiment duration: 30 minutes
      • sampling rate: 1Hz
      • ambient temperature: 23.5°C

  • During a second experiment the motor-power also was logged. The motor-power is in advance of phase.

  • A third test was made under worse conditions:

    • only 20Ohm resistance is being used (2 x 10Ohm in series) ==> current = 9/20 = 450mA (closer to the maximum RCX output current.) Heat production: 9*0.45=4W

    • the desired temperature is fixed to 50°C

    • Note that if the temperature difference is more important, the RCX will run the output at full power almost all the time and the internal output driver chip will probably react on overheat. (Although this internal heat dissipates inside of the cold RCX.)

      • We will need to test this in a freezer.

  • Other experiment: Run everything on 6 x 1.2V NiMH batteries instead of the AC adapter:
    • The RCX output voltage drops to less than 6V (Philo says that we are loosing 1.3V in the output driver.)
    • Battery voltage drops 0.2V only
    • 50°C are never reached, so motor-power remains 255 all the time
    • the driven output port was connected to SNOOP_LOG in order to see, if SNOOP_LOG switches to boot mode or to datalogging mode. This test is made to see, if we can be loosing the datalogging mode due to battery voltage loss. (Remember that SNOOP_LOG checks one of the RCX output ports for voltage.)
      • ==> even if the voltage falls below 4.5V, SNOOP_LOG still recognizes the RCX and datalogging mode is still set. But, even a very short drop below 4V, triggers boot-mode.
      • ===> we should add a capacitor in parallel to the RCX output that connects to SNOOP_LOG in order to prevent accidental loss of datalogging mode. (Although this never happened in the experiments.)


  • We could reduce the amplitude of the temperature oscillations by simply dividing the main loop time by 2 and increasing the motor power increments to 4 instead of 2.
  • The experiment was done on brand new AA alkaline batteries:
    • The temperature rise time has grown, because of the weaker current.
    • ==> this simple control is sufficient. no need to write a PID-controller that would fill the firmware with plenty of code lines and thus increase the download time and the risk of download error.

  • Don't forget to spray the bottom of SNOOP_LOG and Mootz-board with some electrical isolating varnish. Question: at high altitude the ionisation of the athmosphere is very intense. Could there be undesired reactions with the board?


  • Our payload has been selected for the H.A.L.E. activity this summer !!!
  • We made an important change concerning the LED indicators in order to solve the "1 hour before flight" and "just before flight" issue leading to the following start procedure: (NOTE : the function of the green LED has changed !!!! Yellow LED takes over the role of old green LED. Don't confuse this new yellow LED with the one SNOOP_LOG PC-board, which exclusively is used to produce the reference voltage for the ADC.)

  • SNOOP_LOG receives an open-loop heater. We take a 100Ohm /1W resistor that we fix by soldering to a PC-board (no electric connections to the board.) The resistor is powered from the RCX PortC that also powers the YELLOW LED (former green LED) and that gives SNOOP_LOG the voltage to know the RCX is running the firmware. The radiator is placed beneath SNOOP_LOG with a glass-fiber (and a paper) sheet between both to prevent any short circuit. There is no risk of overheating, so this heater can be used in open loop technic.
  • ==> We call this the 800mW heater   (9^2/100=810mW)

  • The LED indicators have been placed inside of LEGO 1/2 pins and a 1x4 Technic brick with a 2x4 transparent brick on the front:

  • SNOOP_LOG receives a transparent plastic protection with 2 holes for the capacitors and another couple of holes for the wires that connect to the RCX. Note the wires that pass between the protection and the RCX.

  • The RCX bottom box has been cut in order to allow the wires to pass to the outside. The box will receive the optocoupler (between RCX on/off button and SNOOP_LOG) and later the Mootz-board.

  • General aspect of LUXPAK electronics so far: 
    • Note the RCX button that will be used for the "REMOVE BEFORE LAUNCH" device.
    • Probably it's a good idea to add the top of the red box to the pressure sensor
    • Perhaps we will need to change the ozone-sensor box.
    • Also note the LEGO temperature sensor that will measure the temperature of the payload interior.



  • We forgot to mention what the LEDs in fact represent and how they are linked to the system:
    • Red LED:
      • owned by SNOOP_LOG
      • flashes in the rythm of the bootload-function
      • flashes as data is stored on EEPROM
      • flashes on SNOOP_LOG error (see above)
    • Yellow LED:
      • former green LED on SNOOP_LOG schematics
      • although placed on the PCboard of SNOOP_LOG, this LED is completely powered by the RCX output C, once the firmware is running and has executed the instruction to set this port in forward mode at highest power
      • normally ON while RCX firmware is running
      • flashes on system error (see beneath)
      • since this LED needs a bit more current, we added another 3k9 in parallel to both already existing (see above)
    • Green LED:
      • owned by the RCX
      • powered by RCX sensor port 3 ! (set to "active" 9V-mode)
      • goes ON when the "REMOVE BEFORE LAUNCH" device is activated (we actually use a LEGO touch sensor that will be maintained in "pressed" state until the device is removed.


  • We changed a few things in SNOOP_LOG firmware:
    • now the pause after error state is much shorter
    • error states (especially UART) are cleared after sending the error message via LED
    • we must activate the brown-out protection in the configuration bits (this must be done manually in ULTIMATE ROBOLAB FOR PICs as the Assembler-window appears). The reason is that if SNOOP_LOG looses its voltage, there is enough voltage from the connected electronics to maintain the uC in a floating state. "BODEN_ON" detects this and maintains the processor in reset state as long as the bad voltage condition exists.
    • now we have SNOOP_LOG fimware version 25
    • get .hex  get .asm
  • We designed the RCX firmware in ULTIMATE ROBOLAB with the following functionality:
    • Initialize the RCX with a short selftest:
      • actual version v11
      • get .asm .srec
      • disable normal RUN-button function (the firmware is stopped by switching off the RCX)
      • NOTE: if switched off while SNOOP_LOG is running, SNOOP_LOG still detects some voltage on port C, it thinks there is no firmware on the RCX. So, it sends the firmware, although the RCX doesn't answer. Then, SNOOP_LOG switches ON the RCX and restarts sending the firmware. This may take 10 minutes !!! (so, caution: switch off SNOOP_LOG before the RCX !!)
      • configure sensor ports
      • write "LXPAK" to the display
      • go into error mode (all LEDs are flashing):
        • Error 1: One of the RCX buttons is pressed (all should be free, so open the payload and verify !!)
        • Error 2: "REMOVE BEFORE FLIGHT" - device already removed ==> at system start (1 hour before launch), the device must be correctly in place.
        • Error 3: Temperature-sensor not connected to RCX sensor port 2
        • Error 4: Temperature-sensor not connected to RCX sensor port 1
        • Error 5: this error-state cannot appear at start, but only later, if a reset procedure has been executed ==> power off, wait a few seconds and power on LUXPAK (SNOOP_LOG must be off voltage; it is sufficient that the RCX is switched off manually - do this after having unpowered SNOOP_LOG)
      • now the RCX waits either for "REMOVE BEFORE LAUNCH" or for the RUN-button pressed
        • if the PRGM button is pressed, the old data on EEPROM is send to the PC via RS232
      • switch on green LED
      • reset LUXPAK clock
      • run "main task"
        • test if RCX buttons have been pressed (needed after payload recuperation in order to retrieve data)
          • if PRGM button is pressed, a 0xF7 (2) message is sent to SNOOP_LOG, which then transmits the contents of EEPROM to the PC via RS232 (there was a bug in the ULTIMATE ROBOLAB "send message" function; we fixed it here -red/blue icon)
          • after a PRGM button event and data upload, the RUN button must be pressed to resume datalogging
          • if the RUN button is pressed together with the PRGM button (RUN button first) then the EEPROM buffer pointer is reset and datalogging starts from scratch (if accidentally done, SNOOP_LOG must be switched off and sent back to us in order to recuperate the data.) SO, CAUTION, WHEN MANIPULATING THE RCX !!!
        • test if we have passed 2 hours
          • switch off "heating task"
      • run "heating task"
        • we try to maintain both temperatures above 10°C (see above)
      • run "sampling task"
        • see above

  • We made a long-time test with LUXPAK. Here the results (data has been processed by LABVIEW:
    • slowly growing pressure
    • almost stable ozone values
    • voltage on a potentiometer (one change)
    • voltage on a Light Dependant Resistor (LDR) -evening: voltage slowly grows, while the sun is vanishing; electric light switched
    • RCX time since start (discontinuous point: datalogging stopped and resumed through pressing the PRGM button - data upload)
    • temperature (ambient temp)
    • temperature (measures the SNOOP_LOG heater)
    • RCX battery level
    • other data irrelevant here

    • no SNOOP_LOG errors

  • The actual RCX firmware (version 11) does not respect yet Francis' suggestion to switch on the ozone tube heater some time before launch. He also concluded that no other heater was necessary inside the payload. Further Francis couldn't conclude from theory that the tube heater was able to maintain the sucked in air temperature above 0°C at -50°C outer temperature, although the practical tests are more optimistic. For these reasons, Claude suggests:
    • Install the 800mW heater beneath SNOOP_board in order to maintain SNOOP_LOG under best conditions.. The air-heater is supposed to be enveloped into the isolation material. Thus the temperature might not be equal through the whole box.
    • Have the possibility for a 2W box heater.
    • If the RCX is supposed to do the tube heater switching directly, then the maximum power is 9V*0.4A=3.6W, which is only half of Francis' proposal.
    • ==> Install LUXPAK in a freezing chamber at deepest possible temperature and have the system run for an hour to see how everything works.
  • Yesterday's tests were executed on a simple test bench (see photo below). The graphs show that there is no drift at constant device temperature.

  • The RCX connections must be respected according to the colour code and the directions of the leads:

  • Some more information about SNOOP_LOG       :
    • current:
      • 6.6mA in wait state
      • 6.6 - 7.3mA during datalogging
      • 23.9mA during data upload
      • 7.39 - 13.86mA during boot-loading (current oscillates at about 0.5Hz)
    • brown-out:
      • PIC16F88 data sheet specifies that if the uC voltage drops below 4V during more than 100us, then the brown-out situation will reset the chip and maintain the reset condition as long as the voltage doesn't rise over 4V.
      • ==> low battery situation at system start will be recognized through 1Hz red LED flashing (probably SNOOP_LOG tried to bootload the RCX, but didn't succeed due to voltage-drop. The chip falls into brown-out, but since the current is reduced, the voltage may rise over 4V. SNOOP_LOG restarts, but as soon as the IR-LED is activated, the higher current forces anotheer voltage drop a.s.o.
  • We received the accus from CONRAD electronics today. Some data:
    • Article 250407 !!! (They changed the article...???)
    • NiMH
    • 1.2V
    • 28g !!!
    • max. discharge current : 3C
    • no information about self-discharge features
      • batteries arrived well charged, so we may suppose that they have low self-discharge characteristics
CONRAD 2700mAh accu specifications
  • Now we also have a power-supply wiring bridge that distributes the battery voltage to the different devices.
  • Everything may now be switched on through one single button.
  • Note that the RCX and the ozone sensor are powered through their AC or DC adapter plug.
  • Mootz_board and the pressure sensor use the same free wire
  • SNOOP_LOG now also is powered with 12V.

  • Maximum current ratings during flight:

    RCX (idle)


    RCX portC (yellow LED + SNOOP_LOG 800mW heater) 91mA
    RCX port3 (green LED) 2.5mA
    RCX portB (2W heater) 225mA
    RCX portA (4W heater) 450mA
    RCX IR-transmission 10mA (estim.)
    Pressure sensor 12mA
    Mootz-board with light sensor and PT100 20mA (?? not measured yet)
    Ozone sensor 40mA
    TOTAL 891.5mA
  • Rather important consumption. But:
    • As Francis calculated and experimented: the heavy heaters won't be active all the time.

    • The accus are brand new.

    • Let's suppose that the accus will loose 20% of their energy during transportation fron Lux to Reno, we still have about 2000mAh charge.

    • Don't forget the 1 hour before flight powering of the ozone sensor, where we drain : 216.5mA (everything is working, except both heavy heaters.) ==> the system may completely run during (2000-216.5)/891.5 = 2 hours.

    • ==> we need to test this and see, if the batteries need to be recharged by Eric Wang before flight.

  • An important issue with LUXPAK/RCX firmware v.11 has appeared during system tests:
    • Both RCX controlled temperature sensors use the RCX ROM conversion from raw ADC value to 1/10°C.
    • If the temperature grows beyond 60°, the returned temperature is 9999.9 !!!
    • The reason for this must be searched in the conversion function of the NTC raw data. Because the RCX uses integer values only, LEGO engineers choose a linearization method that uses intervals of linear equations with the parameters shown in the following diagram:

  • But the authors of the RCX ROM function 0x14c0 added limitations. If raw values are strictly smaller than 290 or greater than 928 then the function returns the value 0x7FFF, which is displayed by 9999.9, since the RCX display cannot show larger numbers.

  • Nothing prevents us from using the first and the last linearization parameters for raw values out of the ROM range. The only condition is that the sensor values cannot be used directly, but must be verified and adjusted before use.

  • Since we are using an original LEGO temperature sensor inside of the box and a NTC thermistor from the shelf (CONRAD part number 195596), we must calibrate this sensor.
  • Datalogging the temperature values of both sensors during a simple experiment shows that they are almost simply offset by :
    • TLEGO = TNTC - 6.2

  • The weight list changes to:

    Polystyrene box


    Glass-wool 116g
    RCX 115g
    SNOOP_LOG 50g
    O3-sensor 134g
    Pressure sensor 36g
    Mootz-board with light sensor and PT100 80g
    Heating resistors (tube) 64g
    Box heating resistors 9g
    SNOOP_LOG heater 50g
    LEGO temperature sensor 8g
    Wires, switch, LED-holder, NTC, touch sensor 80g
    Ozone sensor box 40g
    LEGO pieces 100g
    Silica gel 8g
    Tube for support string 20g
    NiMH accu pack 309g
    TOTAL 1519g


  • We accidentally pressed both buttons (RUN/PRGM) together, where we should have pressed the PRGM button alone... and the RCX sends the fatal message 0xF7 (0x39) to SNOOP_LOG which resets the EEPROM buffer pointer and puts LUXPAK into ERROR 5.
    • ==> we absolutely need another button combination that will not be possible with one finger. As is, LUXPAK gives not well access to the RCX VIEW and ON/OFF buttons. Thus, we will instead use the combination RUN/VIEW. The combination PRGM/ON_OFF produces an RCX reset. It won't be possible to press the RUN and the VIEW buttons with one finger... accidental erase is avoided.
    • ==> we also need clear user guidlines for LUXPAK troubleshooting in the case of errors.
Important detail that we forgot to mention so far:
2 of the crew members are hams: Jean Mootz LX1SK and Claude Baumann LX1BW
The Convict Episcopal's ham identification number is LX9CC
  • Note to yesterday's temperature test: the RCX was placed inside of a non-isolated - but air-proof- box in a normal freezer at -18°C during one hour. At the end of the experiment, at the opening of the box, the RCX was completely wet, which could be fatal for electronics. We conclude from this experiment that we will need inside of LUXPAK:
    • silica-gel to absorb as much as possible humidity during the warm phase of the flight
    • keep the box interior warmer than the dew point
      • QUESTION: how does the dew point evolve during ascension?
  • Operated another long-duration test in order to measure the increase of the temperature inside of the box and next to SNOOP_LOG board (800mW heater):
    • LUXPAK was first placed in an environment at 13°C during 3000sec, then at ambient temperature of 23°C
    • The polystyrene box was closed
    • Except Mootz_board, the box-heater and the tube heater system, every device was powered
    • Ozone-sensor accus was completely empty
    • Use of new accu-pack
      • ==> Observations:
        • Ozone sensor heats to about 35°C
        • Box temperature rises, if the outer temperature higher
        • 800mW heater reaches an unregulated steady state temperature that is about 20° above the outside temperature
        • box temperature doesn't rise at low outside temperature
        • RCX regulates the voltage very, very carefully: no variation - astonishingly - compared to the previous tests with the AC-adapter


  • This stratosphere balloon activity is not gender specific. The Ecole Privée Fieldgen for girls is going to launch a meteo balloon with a payload that measures temperature, pressure, light intensity and takes photos during the ascension. The data is directly sent by radio to the ground. It doesn't seem that they worry about the temperature inside of the payload box. However they wrap aluminium foil around the box. Great project !


Fieldgen, Luxembourg's most known private school for girls is launching a meteo-balloon to the stratosphere from the center of Luxembourg-City
  • Jean Mootz an d Francis Massen worked hard on the calibration of the PT100 temperature sensor. Because Mootz_board isn't temperature compensated they experimentally established calibration functions for various temperature classes. Mootz_board will be placed inside of the battery-pack. The RCX electronics will probably provide enough heat to maintain the board in a most linear section.
  • They also worked on the ozone-sensor air-heating problem. Using a very sensitive and rapid temperature sensor, they tried to heat an air-flow at different speeds and temperatures. Francis will present a detailed report of the experiment. Even after the experiment it is not clear, if we will succeed to heat the air to more than 0° at deep ouside temperatures. The best idea is to use a magnetic pneumatic valve, let in a certain quantity of air that is heated and sucked to the ozone sensor. Francis looked around and could not find any LEGO magnetic valve. However there exists one from Fischer Technik.
  • Yesterday's meeting with Francis:
    • We repeated the air-heating experiment and decided that it probably will be sufficient to control the flow by reducing the diameter of the tube. The main silicon tube has an outer diameter of 6mm that is needed to have contact with the resistors. But we will add a reduction at the outlet in direction of the ozone sensor.
    • Here Claude while repeating the simulation of the ascension air-flow:

  • Francis with the Mootz_board showing the PT100 temperature sensor for instance:

  • LUXPAK's actual stage of being:

  • We decided to add about 100g silica-gel to LUXPAK. (It must be reactivated.)

  • The air-tube heating will be definitely powered by the RCX. Inside of the isolation pack, the RCX will then try to maintain a temperature of 100°C to heat both the tube and by dissipation also the LUXPAK interior. No other heater (except the SNOOP_LOG 800mW heater) will be needed. However, the heating resistors will be distributed over two RCX output ports. There are 6 resistors of 30Ohm each. If they are soldered like indicated on the schematics below, each RCX port will be loaded with 30*60/(30+60)=20Ohm and the maximal current will be 450mA, that we already tested with the RCX. The resistor block needs about a quarter of an hour to be heated at 100°C, that could be effectuated during the phase of the ascension through hot air. The steady state inside of the isolation block is about 150°C. Inside of LUXPAK this probably would be higher, since the heat is dissipated in a worse way. Anyway, the RCX will regulate the temperature to 100°C. As a security, there are:

    • the RCX driver current limitation

    • the RCX fuse (this would be fatal, because LUXPAK woulod be dead. But, as Philo says, the fuse only reacts at 1.5A)

    • the inner temperature sensor that will tell the RCX that there should be a heating reduction.

  • We also soldered the pressure sensor and Mootz_board to the main power supply.

  • Many thanks to LCD meteo for all the expensive sensors and pieces (like the silicon tubes).

  • Some studs of the RCX battery pack had to be cut to accept Mootz_board. (Sorry LEGO). Note the 400Ohm resistor that has been added to the board. (Schematics still missing.)

  • The students group worked on the rather complex problem of how to fix LUXPAK's interior to the polystyrene box. One evening of discussions, tries and errors. But, unlike normal LEGO engineering, some trials cannot be done, because they need cutting and glueing. In this case, solutions have to be anticipated and well reflected, because they cannot be "un-done".

  • The group decides to place the battery pack, where the Ozone sensor was placed before. LEGO plates and bricke will be added to hold it. One major issue is that another tube must pass through the payload, where the balloon-string is passed through. We first thought of using a rigid aluminium tube, but the thermal conduction will make of it a freezing element inside of the box. Francis suggested to use a silicon tube instead. Eric Wang reported in an email that they are commonly using a drinking straw. Anyway, the string passing through the payload causes a major problem of the disposition. Here the position of the accu pack:

  • The transparent box that should have enveloped the ozone-sensor was a bit too weak for the new idea shown on the next picture:

  • The buttons and LEDs will be fixed on the box side. First idea was to fix the PT100 on the same side, but as the sun may shine on it, there could be useless values. The light-sensor is fixed to the bottom, as excentrically as possible, to avoid to many influences of the payloads that might be fly below LUXPAK. PT100 will be fixed in proximity to the light-sensor (simply glued to drilled holes.)

  • The "remove before launch" button is very sensitive to any weak release. The group proposes to fix a LEGO beam that strongly presses the button (a bullet of nylon hot glue could even be added to press it deeply.) Before launch this beam has to be taken off:

  • The main engine button will be glued to the box, after having cut a rectangular emplacement. A LEGO plate will be fixed to the main structure (using 1/2 pins) and glued to the top of the button as a counter-force to the button-pushing:

  • Thierry is re-soldering the resistors:


  • Last-minute proposal:
    • Mootz_board requires the information of the board-temperature because of the temperature-characterstics
    • We were not able to establish a concluding theoretical model for the ozone tube heating. It would be most interesting to control the temperature at the ozone-sensor entrance
    • The temperature of LUXPAK interior must be known, in order to prevent overheating, or deduce, if our heating perhaps was insuffcient
      • ==> rapidly build Mike GASPERI's RCX input mux and use 3 NTCs (10k at 25°C) on one RCX input port instead of the original LEGO temperature sensor
      • add a 2-bit marker to the sensor value in order to let SNOOP_LOG and later the PC identify the specific sensor
    • A new Gasperi input multiplexer was prepared in EAGLE in half an hour, etched and soldered in 1 hour and tested in another half an hour. Everything works fine. We only replaced the 2k2 with a 1k resistor and the 3k9 (3k3) with the 2k2. This returns lower values, where more linearity can be expected for the NTCs, but the RCX sensor percent mode can no longer be applied:

  • For the first tests we used two fix resistors and 1 CdS light sensor. The RCX was programmed that a single pressing of the RCX PRGM button would shortly toggle from "reflection" type to "switch" type, keeping the mode always "raw". Mike's reference point, where the sensor returns 100% in percent mode corresponds to a raw value of 308 (through 1k resistor). A 10k resistor on one of the inputs returns 660 and a 3k9 resistor returns 530. We now will proceed to the NTC calibration and reprogram LUXPAK's RCX according to all the new requirements. 

Got an email from Brian Davis. He announces that he managed to set up an open Internet forum about the HALE mission: