|
Projects
Hosted
Other Cool Stuff
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:
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-Tlm | D-Tlm | D-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: | 5 | 5 | 5 |
|
|
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
|