Amateur Radio on Balloons - Ilmari 2003 IHU
 

Support Our Cause

 

The Ilmari Project is not a Viestikallio Project, this just happened to be a place where we could host these web-pages...

Ilmari Housekeeper Unit


IHU v11

IHU v.11 B -- Components renumbered in style: ICssnn, where "ss" = sheet, "nn" = number within the sheet

IHU v.11

The IO facilities:

  • NMEA 3V CMOS logic level output (RS232 polarity!)
  • iTrax02 iTalk console + IHU console (RS232)
  • JTAG/OnCE for CPU software development tool
  • DTMF receiver (MT88L70) (audio in: 16 .. 480 mV p-p)
  • DDS 3.6 MHz CW/MFSK (0 .. 0.6V, >1kR ) + PTT (3V, I/O) + PSEL (3V, I/O)
  • DDS 10.x MHz CW/MFSK (0 .. 0.6V, >1kR ) + PTT (3V, I/O) + PSEL (3V, I/O)
  • P3-style 400 baud BPSK data source, CMOS, 3V, output
  • APRS/AUDIO DAC out (3V p-p), PTT (3V, I/O), TIMER-#22 (3V, I/O)
  • CMOS HV-IO:
    • 5V CMOS logic
    • 24 mux inputs
    • 24 mux outputs
    • 4 direct inputs (PA0, PB4, PB5, PB7)
  • 33 Analog-inputs (0 - 5.0 voltia)
  • 3 separate timer-IO lines (timer-10, timer-11, and timer-13) (3V, I/O)
  • 5 separate level-/edge-sensitive IO lines (3V, I/O)

Changes to previous version:

  • Change HV-CMOS interface logic chips into 5V HCMOS chips, outputs from RESET-able registers, which go to zero at power-up.
  • Layout changes after those interface chip changes.


IHU v10

IHU v.10

TODO: IHU Master-Oscillator is a problem.. 48.000 MHz, 3.0 volts, pure spectrum, low energy consumption...
Separate project on "DIP-14" substrate! (or a commercial product)
Fairchild AN-340 CMOS Crystal Oscillators ??

Rate Gyro spin-sensor ? (Silicon Sensing, UK), (Analog Devices, USA).
An A/D signal of 0..5V; separate box.

Main components:

The IO facilities:

  • NMEA 3V CMOS logic level output (RS232 polarity!)
  • iTrax02 iTalk console + IHU console (RS232)
  • JTAG/OnCE for CPU software development tool
  • DTMF receiver (MT88L70) (audio in: 16 .. 480 mV p-p)
  • DDS 3.6 MHz CW/MFSK (0 .. 0.6V, >1kR ) + PTT (3V, I/O) + PSEL (3V, I/O)
  • DDS 10.x MHz CW/MFSK (0 .. 0.6V, >1kR ) + PTT (3V, I/O) + PSEL (3V, I/O)
  • P3-style 400 baud BPSK data source, CMOS, 3V, output
  • APRS/AUDIO DAC out (3V p-p), PTT (3V, I/O), TIMER-#22 (3V, I/O)
  • CMOS HV-IO:
    • 5-12 V CMOS logic, depends upon feeding regulator
    • 24 mux inputs
    • 24 mux outputs
    • 1 direct output (PA1)
    • 4 direct inputs (PA0, PB4, PB5, PB7)
  • 33 Analog-inputs (0 - 5.0 voltia)
  • 3 separate timer-IO lines (timer-10, timer-11, and timer-13) (3V, I/O)
  • 5 separate level-/edge-sensitive IO lines (3V, I/O)

Changes to previous version:

  • Changed A/D inputs pre-multiplexers (4 → 8) ⇒ layout changed
  • Due to lack of real-estate, board enlargement was needed, to move power aside
  • Lengthening the board altered digital-io area geometry


IHU v9

IHU v.9 schematics (PDF, 1.0MB), parts list(txt, 18kB) Bill-of-Materials(txt, 36kB) board layout (GIF, 120kB). (100x120 mm)

Main components:

The IO facilities:

  • NMEA 3V CMOS logic level output (NOT RS232!)
  • iTrax02 iTalk console + IHU console (RS232)
  • JTAG/OnCE for CPU software development tool
  • DTMF receiver (MT88L70)
  • DDS 3.6 MHz CW/MFSK (0 .. 0.6V) + PTT (3V, I/O) + PSEL (3V, I/O)
  • DDS 10.x MHz CW/MFSK (0 .. 0.6V) + PTT (3V, I/O) + PSEL (3V, I/O)
  • P3-style 400 baud BPSK data source, CMOS, 3V, output
  • APRS/AUDIO DAC out (3V p-p), PTT (3V, I/O), TIMER-#22 (3V, I/O)
  • CMOS HV-IO:
    • 5-12 V CMOS logic, depends upon feeding regulator
    • 24 mux inputs
    • 24 mux outputs
    • 1 direct output (PA1)
    • 4 direct inputs (PA0, PB4,PB5,PB7)
  • 18 Analog-inputs (0 - 5.0 voltia)
  • 2 separate timer-IO lines (timer-10 ja timer-13) (3V, I/O)
  • 3 separate level-/edge-sensitive IO lines (3V, I/O)

IHU v8

No English translation of these historic versions

IHU v.8 kytkentäkaavio (PDF, 1.5MB), board-layout (PDF, 1.0MB). (100x120 mm) (TODO: power supply; tilaa: 20x35 mm²)

TODO: Master-oskillaattorista on vaikeuksia.. 48.000 MHz 3.0 voltilla nakuttava.. Fairchild AN-340 CMOS Crystal Oscillators ??

IHU v6

No English translation of these historic versions

Ilmari Housekeeper Unit skema: v.6, PDF: 28 yleis-IO-linjaa, joista 8:ssa A/D muuntimen ottoja.

Hahmotelma versiosta 7, jossa on mukana hahmotelmaa 10V CMOS liitäntälogiikkaan ja lisä-A/D ottoihin.

Koskapa nuo liitännät liittimineen, bypasseineen ja sarjavastuksineen veivät paljon korttitilaa, siirrettiin ne kokeeksi erilliseen laajennuskorttiin (70x100mm):

Kytkentäkaavio (PDF) CMOS IO laajennokseen; Käyttösähkö tulee IHU:lta, VDD voi olla välillä 5-15 volttia. (Sittemmin hylätty, tuo logiikka laitetaan IHU:lle ja kytkennät sarjavastuksista IHU:n kotelon seinään laitettaviin pii-filttereihin tehdään parhaaseen hyppylankatyyliin.)

IHU v4

No English translation of these historic versions

ihu skema v.4 (TODO: virtalähde; 20x25 mm² tilaan kortin vasempaan alakulmaan)

päältä:
alta:
Valkoinen kehysviiva molemmissa y.o. kuvissa on 100x80 mm ruutu.

IHU v2

No English translation of these historic versions

Matti, OH1MQK/2, on jatkanut IHU:n skeman piirtämistä: ihu v.2

Kuva Eagle:n (www.cadsoft.de) layout ruudulta.
Puuttuvat osat: Virtalähde, lisää digitaaliliitäntöjä ja analogisten inputtien reititys.

Kortti on 2-puolinen, 80x100 mm² ja maatasoa on kaadettu ympäriinsä urakalla:


BPSK modulation:

Petri Kotilainen, OZ/OH3MCK, did simulate 400 bit/s BPSK modulation as doable with DDS direct phase command line, and how it would look in spectrum:

  • Pink: DDS modulated directly via PHASE-select input ⇒ spurs wide and loud...
  • Blue (and green below it): frequency modulations, where output frequency of changed for 1/4 or 1/8 bit duration to be slightly different. Frequency modulation is such that in this time the phase will rotate 180 degrees. One DDS runs above center frequency, other runs below it.
  • Red: Sum of the DDSes, when Blue and Green signals are summed together.
  • For the trick to work, used DDSes must have same phases to a high degree, and frequency changes must occur at precisely same moments.

Wider spectral images:

1/21/41/8


Telemetry data

Fletcher about telemetry/commands:

I pondered this question at previous IRC-meeting (IRC3?), and came up with something like follows. (This is roughly the worst possible case, and the idea is to simulate RATS-SAT, and that mistakes must be learned about):

What:A-TlmD-TlmD-Cmd
Internal temperature:2
External Temperature:1
Translator Internal Temperature:2
Translator ALC:1
Translator input voltage (sw-reg):1
Translator X-tal Oscillator Currents:2
Translator pre-driver current::1
Translator 400 bps BPSK beacon datastream::1
Translator CW/MFSK beacon:1 (DDS 0.6V!)
Translator beacon status:2 (?)
Translator start:1
Translator passband blocking:1
Translator status:1
Translator IF status:1
APRS-TX output power:1
APRS-TX status:1
3.5 MHz beacon transmit power:1
3.5 MHz beacon transmitter ON:1
3.5 MHz beacon status:1
14 V lithium primary-battery (3.6V) cell voltages:4
1.3 GHz ATV-TX transmitter output power:1
ATV-TX start:1
Balloon release mechanism arming command:1
Balloon release command:1
Balloon release indication:1?1
ATV cameras:1
ATV camera control:1
Camera status:1
Film (still) camera trigger:1
Total: 16 9 10
Spares:555
Total: 22 14 15

NOTE: IHU has 33 A/D inputs (0.0 - 5.0 volts).

24 CMOS (5 volts) outputs

24+4 CMOS (5 volts) inputs

A group of other I/O lines with 3.0 volt levels

Fletcher tells more:

Due to various priority things I have had very little time to make documentation. Essentially the idea is that in fault condition a line (incoming or outgoing, being shorted to ground or power rail - worst cases) must not prevent other ports from working, nor cause any additional damage. Also the current consumption must stay in its minimum. Transmitter controls, etc. along with their switch transistors must be implemented inside the transmitter et.al. boxes. Controls shall be about 10V (to reduce current (the editor wonders about this explanation) and source as well as load impedances shall be as large as practical, preferrably over 10 k-ohms.

A few days latter Flecther said to have been lowerred the voltage specification to 5.0 volts.   This does depend on what shall be the general regulated voltage in the system.


About Telemetry:


MIM-module sends APRS as:
  • Raw NMEA ($GPGGA record)
  • Telemetry Report Frame
GPS outputs a NMEA message ($GPGGA), which MIM sends on as is. After it MIM sends telemetry packet.

"I think MIM sends thru only these GPS GGA messages."

What Timo Pekurinen said, when asking about the thing from him...

AX.25 UI frame contains:

  • Destination Address{7}: "ALL___-_" ? (AX.25 coding rule!)
  • Source Address{7}: "OHxnnn-11" (SSID "-11" = "balloon")
  • Control{1}: 0x03 ( = UI-frame )
  • ProtocolId{1}: 0xF0 ( = no level 3 AX.25 protocol )
  • APRS payload data {1..256 bytes}, details below:
Frame 16 bytes.


APRS frame:

The new Ilmari Housekeeper Unit could pre-process GPS received NMEA $GPGGA, and $GPVTG messages into APRS "Lat/Long Position Report Format - with Data Extension and Timestamp" format, and send it:

  • "/": Constant ("APRS station with timestamp, no message traffic")
  • Time{7}: HHMMSS+"h", UTC, ei date.
  • Lat{8}: DDMM.MM+"N"; degrees, and decimal minutes to two decimals, plus "N"/"S" indicator. ("6133.79N")
  • SymTableId{1}: "/"
  • Long{8}: DDDMM.MM+"E"; degrees (000..180), and decimal minutes to two decimals, plus "E"/"W" indicator. ("02358.98E")
  • SymCode{1}: "O" ("Balloon symbol")
  • Course{3}: 001..360 ( "000" is unmoving station )
  • "/": Constant
  • Speed{3}: Speed in knots, integer
  • "/A=" + AltFeet{6}: height in feet in "%06d" format (integer).
  • + telemetry (0..30 bytes) ?
All in all {40 + telemetry} bytes. Maximum is 70 bytes.

With AX25 frame, 56-86 bytes.

All in all XX bytes.

test-ihu-aprs.wav (6000 Hz 8-bit mono, 3.1 kB)

APRS msg:

/223355h6155.99N/02455.88EO030/030/A=-00099

APRS telemetry messages ?

Shall also some standard APRS telemetry message be sent ? If so, what shall it contain ?


MPRS telemetry messages

Within possibilities would also be to send also this kind of messages:

Latitude and Longitude, only.

MPRS packet:

bitsync  16 or more alternating bits, ending with "0"

wordsync SYNC Word 11000100 11010111

0x4?     "MPRS" 0x40=normal,
          0x41...0x4F inclusive are reserved.

5 bytes  packed callsign (6 characters),
         and ssid (4 bits)

1 byte   reserved for routing/digipeating
         "going up/downstream at level X"

3 bytes  latitude        7F 3F 7F
     0x80 of 1st byte: "destination" (GPRMB)
                       or "position" (GPRMC)

3 bytes  longitude       FF 3F 7F

2 bytes  CRC (AX25 way, MSB first, bytes
         between wordsync and crc, seed FFFF,
         complemented)


HF-beacon in 16-FSK-16-F mode ("MFSK16") sends:

  • Call{4..6}: "oh2nxx" (5+6+9+3*7 = 41 bits)
    (each character bit)
  • Suffix{0..3}: "/am" (9+5+7 = 21 bits)
  • Literal{5}: " bcn " (3+9+8+8+3 = 31 bits)
  • Time{6}: HHMMSS (UTC) (6*9 = 54 bits)
  • Latitude{7}: DDMM.mmX ("6133.79n) (7*9+5 = 68 bits)
  • Literal{1}: " " (3 bits)
  • Longitude{8}: DDDMM.mmY ("02358.98e") (8*9+4 = 75 bits)
  • Literal{1}: " " (3 bits)
  • Altitude{5}: 23456 (meters) (5*9 = 45 bits)
  • Literal{1}: " " (3 bits)
  • Course{3}: 012 (3*9 = 27 bits)
  • Literal{1}: " " (3 bits)
  • speed{5}: sss.s * 10 ("0999" = 99.9km/h = 27.75 m/s) (5*9 = 45 bits)
    NOTE: GPS gives km/h and knots...
  • Literal{4}: "m/s " (7+9+6 = 22 bits)
    (62 chars so far) (480 bits)
  • Telemetry message same as with APRS ? (41 chars, 382 bits)
  • Literal{1}: <CR> (ASCII char 13, 8 bits)
Due to Varicode coding this shall use LOWER CASE characters (shorter codes!) All in all 123 chars / max 827 bits (??)

At speed 31.250 bit/sec the MFSK16 transmission takes 26.47 seconds. (pre+post idles: 8+4 symbol times, e.g. 12/15.625 sec = 0.77 sec)   At most 27.24 seconds into the message! Possibly 2..6 symbol times (0.1-0.3 sec) faster transmission due to small compression happening with it.

Telemetry message: ??

  • Literal{2}: "t=" (4+9 = 13 bit)
  • 18 pcs. of 10 bit analog values encoded as two "BASE64" characters
    PERL notaation: $BASE64[ $val / 64 ] . $BASE64[ $val % 64 ];
  • 4 kpl yhdellä "BASE64" merkillä koodattua 6-bitin digitaalitietoa.
  • 4 pcs of "BASE64" character encoded 6-bit digital data.
Total 41 chars.

BASE64 codes are Varikooded with 4-9 bits; lets estimate by the worst: 13+41*9 bits = 382 bits.

test-ihu-mfskcw.wav (8000 Hz 8-bit mono, 477 kB) CW @ 100 CPM + MFSK16..

A one line, which is folded at the "\" character:

oh2nxx/am bcn 135959utc 6133.7988n 02358.9876e 23456m \
012° 99.9kt 13.87v -57c -20c


HF-beacon in CW mode sends:

Average letter length with inter-character space is 9-10 "dots". Inter-word space is 5 dots.

  • Callsign{4..6}: "OH2zzz/AM" (14+10+18+16+16+16+16+8+10 +3 = 127)
    (count of character dots per longest possible code))
  • Latitudi{7}: DDMM.mm ("613379N") (8 + 6*10 + 3 = 90)
  • Longitudi{8}: DDDMM.mm ("235898E") (8 + 6*10 + 3 = 100)
  • Altitude{5}: kkmmm ("00250M") (5*10 + 3 = 53)
  • BatVolt*100-1000{3}: 13.87 ⇒ "387" (3*10+3 = 33)   ???

telemetry will be sent in 30 second intervals by altering in between the MFSK and CW modes.   Location fixes by every 60 seconds!

After CW workers commented on various proposals, following CW message was created:

test-ihu-mfskcw.wav (8000 Hz 8-bit mono, 477 kB) CW @ 100 CPM + MFSK16..

Msg:

OH2NXX/AM 613379n/245587e/02570m


AO-40 telemetria / BASIC & KA9Q-FEC versions

TO BE DEFINED!   Initial draft ideas below...

BASIC: 512 bytes per frame

KA9Q-FEC: 256 bytes per frame (512 bytes including FEC)

6 bytes outside the payload

400 bps BPSK ⇒ 50 bytes/sec ⇒ 10.84 - 11.04 sec per frame

KA9Q-FEC: 13 sec/frame

Data:

0      "A"
1-31   "Hi, This is OH#xxx/AM  Ilmari! "
32-50  "20030917 075655.22 "              Fix time
51-63  "61°57.9876'N "                    Fix Lat
64-79  "021°57.9876'E "                   Fix Long
80-86  "01234m "                          Fix Alt
87-92  "000° "                            Last heading
93-100 "99.99kt "                         Last speed
101-105 "0020 "                           Mission time  hhmm
106-253 Base64 encoded telemetry block (148 bytes = 888 bits)
        - 6-bits per byte
        - 10-bit A/D results take 2 bytes, 33 vals: → 66 chars
        - 30 bit D-out bits                         →  5 chars
        - 30 bit D-in  bits                         →  5 chars
        - Sun-sensor timer data
          last 8 edge jiffy-deltas, 3 chars each    → 24 chars
        - UNSPECIFIED:  ASCII SPACE                 → 81 chars
254-255 AO-40 CRC16 of preceding 254 byte block 
256-511 BASIC only: repeat first 256 byte block ?

Or shall we use binary encoded values packing 2 A/D values into three bytes ?

test-ihu-ao40bpsk-ka9qfec.wav (9600 Hz 8-bit mono, 243 kB)

Simulated spin-fading with varying Eb/N0 values:
test-ihu-ao40bpsk-ka9qfec-fade-ebn10.wav (9600 Hz 8-bit mono, 243 kB)
test-ihu-ao40bpsk-ka9qfec-fade-ebn16.wav (9600 Hz 8-bit mono, 243 kB)
test-ihu-ao40bpsk-ka9qfec-fade-ebn23.wav (9600 Hz 8-bit mono, 243 kB)


IHU software:

  • Receives GPS $GPGGA and $GPVTG messages.
    The latter record (VTG) begins processing
    Validity of positional fix must be checked
    (Testing did show, that this GPS-module does not decrease its power consumption by using "FIXRATE 60", thus we shall get fixes every second..)
  • Base-timer runs at 6000 Hz (APRS D/A output clock), produces 32 bit jiffy-clock (7.7 days to roll over)
  • Checking own clock (6h from start, or something → drop-abort)
  • Checking position within "mission box" (outside 3 successive fixes → drop abort)
  • Measuring analog values, reaading digital ones
  • Send APRS position report (see above), repeating 2-3 times!
  • Sending continuously P3-style BPSK400 data-stream
    • Alternating P3-style "BASIC" dataframes, and "KA9Q-FEC" frames
    • Production of needed continuously running 400 Hz clock square-wave produces 800 Hz interrupt-rate to IHU
  • Sending HF and Translator MFSK16 and CW beacons in sequence.
    • Together a bit under 60 seconds.
    • Send rotation begins always at the first GPS-fix during GPS-minute, or lacking that, a bit latter by timer...
  • All kinds of tricks will be used to conserve electricity
Into some clock interrupt the DTMF decoder polling..

Serial port (GPS, console) read/write via interrupt routines ?


IHU functionality requirements have been listed as:

  • Mission Abort
    • DTMF command
    • Flight-box, e.g. GPS location detects moving outside permitted flight area in N successive location fixes. (Coordinate area in integer minutes for the calculation.)
    • Timer (6h from the beginning of the flight, or some such.)
    • Separate redundant unit with these same functions ?
  • ATV-Xmitter control
    • DTMF command
    • Flight-box, e.g. GPS location detects presense inside of permitted transmit area in N successive location fixes. (Coordinate area in integer minutes for the calculation.) One fix outside the permitted area closes the transmitter.
    • Battery voltage
    • Timer (15/45 sec on/off ?)
    • Transmitter overtemperature/overcurrent ?
  • Transponder control
    • DTMF command
    • Flight-box, e.g. GPS location detects presense inside of permitted transmit area in N successive location fixes. (Coordinate area in integer minutes for the calculation.) One fix outside the permitted area closes the transmitter.
    • Battery voltage
    • Timer ? (total flight-time)
    • Transmitter overtemperature/overcurrent ?
  • 70cm APRS beacon
  • 3.6 MHz CW/MFSK16 beacon

Source code snapshots: ftp://zmailer.org/ilmari/

Matti Aarnio <matti.aarnio@zmailer.org>; OH2MQK

 

Valid HTML 4.01!   Z Elisa Communications
This page is Links enhanced for additional browsing pleasure.