From: Bdale Garbee Date: Tue, 30 Nov 2010 04:56:41 +0000 (-0700) Subject: update docs X-Git-Url: https://git.gag.com/?a=commitdiff_plain;h=e5b5e5aaa74ba1fc594fde9b9df58ee602828cc6;p=web%2Faltusmetrum update docs --- diff --git a/AltOS/doc/altos.html b/AltOS/doc/altos.html index dea05ee..3755032 100644 --- a/AltOS/doc/altos.html +++ b/AltOS/doc/altos.html @@ -1,10 +1,10 @@ -AltOS

AltOS

Altos Metrum Operating System

Keith Packard

+AltOS

AltOS

Altos Metrum Operating System

Keith Packard

This document is released under the terms of the Creative Commons ShareAlike 3.0 license. -

Revision History
Revision 0.122 November 2010
Initial content

Chapter 1. Overview

+

Revision History
Revision 0.122 November 2010
Initial content

Chapter 1. Overview

AltOS is a operating system built for the 8051-compatible processor found in the TI cc1111 microcontroller. It's designed to be small and easy to program with. The main features are: @@ -61,7 +61,7 @@

As you can see, a long sequence of subsystems are initialized and then the scheduler is started. -

Chapter 2. Programming the 8051 with SDCC

The 8051 is a primitive 8-bit processor, designed in the mists of time in as few transistors as possible. The architecture is highly irregular and includes several separate memory @@ -69,7 +69,7 @@ stack itself is of limited size. While SDCC papers over the instruction set, it is not completely able to hide the memory architecture from the application designer. -

8051 memory spaces

+

8051 memory spaces

The __data/__xdata/__code memory spaces below were completely separate in the original 8051 design. In the cc1111, this isn't true—they all live in a single unified 64kB address @@ -83,7 +83,7 @@ is decorated with a memory space identifier which clutters the code but makes the resulting code far smaller and more efficient. -

__data

+

__data

The 8051 can directly address these 128 bytes of memory. This makes them precious so they should be reserved for frequently addressed values. Oh, just to @@ -93,42 +93,42 @@ these registers located at 0x00 - 0x1F. AltOS uses only the first bank at 0x00 - 0x07, leaving the other 24 bytes available for other data. -

__idata

+

__idata

There are an additional 128 bytes of internal memory that share the same address space as __data but which cannot be directly addressed. The stack normally occupies this space and so AltOS doesn't place any static storage here. -

__xdata

+

__xdata

This is additional general memory accessed through a single 16-bit address register. The CC1111F32 has 32kB of memory available here. Most program data should live in this memory space. -

__pdata

+

__pdata

This is an alias for the first 256 bytes of __xdata memory, but uses a shorter addressing mode with single global 8-bit value for the high 8 bits of the address and any of several 8-bit registers for the low 8 bits. AltOS uses a few bits of this memory, it should probably use more. -

__code

+

__code

All executable code must live in this address space, but you can stick read-only data here too. It is addressed using the 16-bit address register and special 'code' access opcodes. Anything read-only should live in this space. -

__bit

+

__bit

The 8051 has 128 bits of bit-addressible memory that lives in the __data segment from 0x20 through 0x2f. Special instructions access these bits in a single atomic operation. This isn't so much a separate address space as a special addressing mode for a few bytes in the __data segment. -

__sfr, __sfr16, __sfr32, __sbit

+

__sfr, __sfr16, __sfr32, __sbit

Access to physical registers in the device use this mode which declares the variable name, it's type and the address it lives at. No memory is allocated for these variables. -

Function calls on the 8051

+

Function calls on the 8051

Because stack addressing is expensive, and stack space limited, the default function call declaration in SDCC allocates all parameters and local variables in static global @@ -136,7 +136,7 @@ non-reentrant, and also consume space for parameters and locals even when they are not running. The benefit is smaller code and faster execution. -

__reentrant functions

+

__reentrant functions

All functions which are re-entrant, either due to recursion or due to a potential context switch while executing, should be marked as __reentrant so that their parameters and local @@ -149,7 +149,7 @@ invoked can also be marked as __reentrant. The resulting code will be larger, but the savings in memory are frequently worthwhile. -

Non __reentrant functions

+

Non __reentrant functions

All parameters and locals in non-reentrant functions can have data space decoration so that they are allocated in __xdata, __pdata or __data space as desired. This can avoid @@ -161,14 +161,14 @@ non-reentrant. Because of this, interrupt handlers must not invoke any library functions, including the multiply and divide code. -

__interrupt functions

+

__interrupt functions

Interrupt functions are declared with with an __interrupt decoration that includes the interrupt number. SDCC saves and restores all of the registers in these functions and uses the 'reti' instruction at the end so that they operate as stand-alone interrupt handlers. Interrupt functions may call the ao_wakeup function to wake AltOS tasks. -

__critical functions and statements

+

__critical functions and statements

SDCC has built-in support for suspending interrupts during critical code. Functions marked as __critical will have interrupts suspended for the whole period of @@ -177,9 +177,9 @@ that statement. Keeping critical sections as short as possible is key to ensuring that interrupts are handled as quickly as possible. -

Chapter 3. Task functions

This chapter documents how to create, destroy and schedule AltOS tasks. -

ao_add_task

+    

ao_add_task

 	void
 	ao_add_task(__xdata struct ao_task * task,
 	            void (*start)(void),
@@ -190,12 +190,12 @@
 	display), and the start address. It does not switch to the
 	new task. 'start' must not ever return; there is no place
 	to return to.
-      

ao_exit

+      

ao_exit

 	void
 	ao_exit(void)
       

This terminates the current task. -

ao_sleep

+      

ao_sleep

 	void
 	ao_sleep(__xdata void *wchan)
       

@@ -215,7 +215,7 @@ __critical while (!ao_radio_done) ao_sleep(&ao_radio_done);

-

ao_wakeup

+      

ao_wakeup

 	void
 	ao_wakeup(__xdata void *wchan)
       

@@ -233,7 +233,7 @@ ao_sleep block can only be run from normal mode, and so this sequence can never be interrupted with execution of the other sequence. -

ao_alarm

+      

ao_alarm

 	void
 	ao_alarm(uint16_t delay)
       

@@ -250,19 +250,19 @@ incoming radio data. If no data is received before the timeout fires, ao_sleep will return 1 and then this code will abort the radio receive operation. -

ao_wake_task

+      

ao_wake_task

 	void
 	ao_wake_task(__xdata struct ao_task *task)
       

Force a specific task to wake up, independent of which 'wchan' it is waiting for. -

ao_start_scheduler

+      

ao_start_scheduler

 	void
 	ao_start_scheduler(void)
       

This is called from 'main' when the system is all initialized and ready to run. It will not return. -

ao_clock_init

+      

ao_clock_init

 	void
 	ao_clock_init(void)
       

@@ -271,7 +271,7 @@ internal devices like USB. It should be called by the 'main' function first, before initializing any of the other devices in the system. -

Chapter 4. Timer Functions

+

Chapter 4. Timer Functions

AltOS sets up one of the cc1111 timers to run at 100Hz and exposes this tick as the fundemental unit of time. At each interrupt, AltOS increments the counter, and schedules any tasks @@ -279,51 +279,51 @@ collect current data readings. Doing this from the ISR ensures that the ADC values are sampled at a regular rate, independent of any scheduling jitter. -

ao_time

+    

ao_time

 	uint16_t
 	ao_time(void)
       

Returns the current system tick count. Note that this is only a 16 bit value, and so it wraps every 655.36 seconds. -

ao_delay

+      

ao_delay

 	void
 	ao_delay(uint16_t ticks);
       

Suspend the current task for at least 'ticks' clock units. -

ao_timer_set_adc_interval

+      

ao_timer_set_adc_interval

 	void
 	ao_timer_set_adc_interval(uint8_t interval);
       

This sets the number of ticks between ADC samples. If set to 0, no ADC samples are generated. AltOS uses this to slow down the ADC sampling rate to save power. -

ao_timer_init

+      

ao_timer_init

 	void
 	ao_timer_init(void)
       

This turns on the 100Hz tick using the CC1111 timer 1. It is required for any of the time-based functions to work. It should be called by 'main' before ao_start_scheduler. -

Chapter 5. AltOS Mutexes

Table of Contents

ao_mutex_get
ao_mutex_put

+

Chapter 5. AltOS Mutexes

Table of Contents

ao_mutex_get
ao_mutex_put

AltOS provides mutexes as a basic synchronization primitive. Each mutexes is simply a byte of memory which holds 0 when the mutex is free or the task id of the owning task when the mutex is owned. Mutex calls are checked—attempting to acquire a mutex already held by the current task or releasing a mutex not held by the current task will both cause a panic. -

ao_mutex_get

+    

ao_mutex_get

 	void
 	ao_mutex_get(__xdata uint8_t *mutex);
       

Acquires the specified mutex, blocking if the mutex is owned by another task. -

ao_mutex_put

+      

ao_mutex_put

 	void
 	ao_mutex_put(__xdata uint8_t *mutex);
       

Releases the specified mutex, waking up all tasks waiting for it. -

Chapter 6. CC1111 DMA engine

+

Chapter 6. CC1111 DMA engine

The CC1111 contains a useful bit of extra hardware in the form of five programmable DMA engines. They can be configured to copy data in memory, or between memory and devices (or even between @@ -340,7 +340,7 @@ from hardware to memory, that trigger event is supplied by the hardware device. When copying data from memory to hardware, the transfer is usually initiated by software. -

ao_dma_alloc

+    

ao_dma_alloc

 	uint8_t
 	ao_dma_alloc(__xdata uint8_t *done)
       

@@ -351,7 +351,7 @@ AO_DMA_ABORTED bit if ao_dma_abort was called. Note that it is possible to get both bits if the transfer was aborted after it had finished. -

ao_dma_set_transfer

+      

ao_dma_set_transfer

 	void
 	ao_dma_set_transfer(uint8_t id,
 	                    void __xdata *srcaddr,
@@ -365,24 +365,24 @@
 	cfg1 are values directly out of the CC1111 documentation
 	and tell the DMA engine what the transfer unit size,
 	direction and step are.
-      

ao_dma_start

+      

ao_dma_start

 	void
 	ao_dma_start(uint8_t id);
       

Arm the specified DMA engine and await a signal from either hardware or software to start transferring data. -

ao_dma_trigger

+      

ao_dma_trigger

 	void
 	ao_dma_trigger(uint8_t id)
       

Trigger the specified DMA engine to start copying data. -

ao_dma_abort

+      

ao_dma_abort

 	void
 	ao_dma_abort(uint8_t id)
       

Terminate any in-progress DMA transation, marking its 'done' variable with the AO_DMA_ABORTED bit. -

Chapter 7. SDCC Stdio interface

+

Chapter 7. SDCC Stdio interface

AltOS offers a stdio interface over both USB and the RF packet link. This provides for control of the device localy or remotely. This is hooked up to the stdio functions in SDCC by @@ -390,13 +390,13 @@ automatically multiplex the two available communication channels; output is always delivered to the channel which provided the most recent input. -

putchar

+    

putchar

 	void
 	putchar(char c)
       

Delivers a single character to the current console device. -

getchar

+      

getchar

 	char
 	getchar(void)
       

@@ -404,13 +404,13 @@ console devices. The current console device is set to that which delivered this character. This blocks until a character is available. -

flush

+      

flush

 	void
 	flush(void)
       

Flushes the current console device output buffer. Any pending characters will be delivered to the target device. - xo

ao_add_stdio

+      xo	  

ao_add_stdio

 	void
 	ao_add_stdio(char (*pollchar)(void),
 	                   void (*putchar)(char),
@@ -432,13 +432,13 @@
 	'flush' forces the output buffer to be flushed. It may
 	block until the buffer is delivered, but it is not
 	required to do so.
-      

Chapter 8. Command line interface

AltOS includes a simple command line parser which is hooked up to the stdio interfaces permitting remote control of the device over USB or the RF link as desired. Each command uses a single character to invoke it, the remaining characters on the line are available as parameters to the command. -

ao_cmd_register

+    

ao_cmd_register

 	void
 	ao_cmd_register(__code struct ao_cmds *cmds)
       

@@ -469,38 +469,38 @@ The command line is invalid for some reason other than invalid tokens.

-

ao_cmd_lex

+      

ao_cmd_lex

 	void
 	ao_cmd_lex(void);
       

This gets the next character out of the command line buffer and sticks it into ao_cmd_lex_c. At the end of the line, ao_cmd_lex_c will get a newline ('\n') character. -

ao_cmd_put16

+      

ao_cmd_put16

 	void
 	ao_cmd_put16(uint16_t v);
       

Writes 'v' as four hexadecimal characters. -

ao_cmd_put8

+      

ao_cmd_put8

 	void
 	ao_cmd_put8(uint8_t v);
       

Writes 'v' as two hexadecimal characters. -

ao_cmd_white

+      

ao_cmd_white

 	void
 	ao_cmd_white(void)
       

This skips whitespace by calling ao_cmd_lex while ao_cmd_lex_c is either a space or tab. It does not skip any characters if ao_cmd_lex_c already non-white. -

ao_cmd_hex

+      

ao_cmd_hex

 	void
 	ao_cmd_hex(void)
       

This reads a 16-bit hexadecimal value from the command line with optional leading whitespace. The resulting value is stored in ao_cmd_lex_i; -

ao_cmd_decimal

+      

ao_cmd_decimal

 	void
 	ao_cmd_decimal(void)
       

@@ -508,7 +508,7 @@ line with optional leading whitespace. The resulting value is stored in ao_cmd_lex_u32 and the low 16 bits are stored in ao_cmd_lex_i; -

ao_match_word

+      

ao_match_word

 	uint8_t
 	ao_match_word(__code char *word)
       

@@ -516,14 +516,14 @@ line. It does not skip leading white space. If 'word' is found, then 1 is returned. Otherwise, ao_cmd_status is set to ao_cmd_syntax_error and 0 is returned. -

ao_cmd_init

+      

ao_cmd_init

 	void
 	ao_cmd_init(void
       

Initializes the command system, setting up the built-in commands and adding a task to run the command processing loop. It should be called by 'main' before ao_start_scheduler. -

Chapter 9. CC1111 USB target device

The CC1111 contains a full-speed USB target device. It can be programmed to offer any kind of USB target, but to simplify interactions with a variety of operating systems, AltOS provides @@ -537,7 +537,7 @@ interface if desired, offering control of the device over the USB link. Alternatively, the functions can be accessed directly to provide for USB-specific I/O. -

ao_usb_flush

+    

ao_usb_flush

 	void
 	ao_usb_flush(void);
       

@@ -545,7 +545,7 @@ to be delivered to the USB host if there is pending data, or if the last IN packet was full to indicate to the host that there isn't any more pending data available. -

ao_usb_putchar

+      

ao_usb_putchar

 	void
 	ao_usb_putchar(char c);
       

@@ -554,7 +554,7 @@ adds a byte to the pending IN packet for delivery to the USB host. If the USB packet is full, this queues the 'IN' packet for delivery. -

ao_usb_pollchar

+      

ao_usb_pollchar

 	char
 	ao_usb_pollchar(void);
       

@@ -562,13 +562,13 @@ packet received, this returns AO_READ_AGAIN. Otherwise, it returns the next character, reporting to the host that it is ready for more data when the last character is gone. -

ao_usb_getchar

+      

ao_usb_getchar

 	char
 	ao_usb_getchar(void);
       

This uses ao_pollchar to receive the next character, blocking while ao_pollchar returns AO_READ_AGAIN. -

ao_usb_disable

+      

ao_usb_disable

 	void
 	ao_usb_disable(void);
       

@@ -583,7 +583,7 @@ after disabling the USB device, it's likely that the cable will need to be disconnected and reconnected before it will work again. -

ao_usb_enable

+      

ao_usb_enable

 	void
 	ao_usb_enable(void);
       

@@ -591,7 +591,7 @@ disabled. See the note above about needing to physically remove and re-insert the cable to get the host to re-initialize the USB link. -

ao_usb_init

+      

ao_usb_init

 	void
 	ao_usb_init(void);
       

@@ -599,7 +599,7 @@ the control end point and adds the usb I/O functions to the stdio system. Call this from main before ao_start_scheduler. -

Chapter 10. CC1111 Serial peripheral

+

Chapter 10. CC1111 Serial peripheral

The CC1111 provides two USART peripherals. AltOS uses one for asynch serial data, generally to communicate with a GPS device, and the other for a SPI bus. The UART is configured to operate @@ -610,25 +610,25 @@

To prevent loss of data, AltOS provides receive and transmit fifos of 32 characters each. -

ao_serial_getchar

+    

ao_serial_getchar

 	char
 	ao_serial_getchar(void);
       

Returns the next character from the receive fifo, blocking until a character is received if the fifo is empty. -

ao_serial_putchar

+      

ao_serial_putchar

 	void
 	ao_serial_putchar(char c);
       

Adds a character to the transmit fifo, blocking if the fifo is full. Starts transmitting characters. -

ao_serial_drain

+      

ao_serial_drain

 	void
 	ao_serial_drain(void);
       

Blocks until the transmit fifo is empty. Used internally when changing serial speeds. -

ao_serial_set_speed

+      

ao_serial_set_speed

 	void
 	ao_serial_set_speed(uint8_t speed);
       

@@ -636,14 +636,14 @@ AO_SERIAL_SPEED_4800, AO_SERIAL_SPEED_9600 or AO_SERIAL_SPEED_57600. This first flushes the transmit fifo using ao_serial_drain. -

ao_serial_init

+      

ao_serial_init

 	void
 	ao_serial_init(void)
       

Initializes the serial peripheral. Call this from 'main' before jumping to ao_start_scheduler. The default speed setting is AO_SERIAL_SPEED_4800. -

Chapter 11. CC1111 Radio peripheral

The CC1111 radio transceiver sends and receives digital packets with forward error correction and detection. The AltOS driver is fairly specific to the needs of the TeleMetrum and TeleDongle @@ -681,7 +681,7 @@ receiver. This is designed to provide a beacon to track the device when other location mechanisms fail.

-

ao_radio_set_telemetry

+    

ao_radio_set_telemetry

 	  void
 	  ao_radio_set_telemetry(void);
 	

@@ -690,7 +690,7 @@ other RF parameters. It does not include the base frequency or channel though. Those are set at the time of transmission or reception, in case the values are changed by the user. -

ao_radio_set_packet

+	

ao_radio_set_packet

 	  void
 	  ao_radio_set_packet(void);
 	

@@ -699,7 +699,7 @@ parameters. It does not include the base frequency or channel though. Those are set at the time of transmission or reception, in case the values are changed by the user. -

ao_radio_set_rdf

+	

ao_radio_set_rdf

 	  void
 	  ao_radio_set_rdf(void);
 	

@@ -709,26 +709,26 @@ and data whitening logic is turned off so that the resulting modulation is received as a 1kHz tone by a conventional 70cm FM audio receiver. -

ao_radio_idle

+	

ao_radio_idle

 	  void
 	  ao_radio_idle(void);
 	

Sets the radio device to idle mode, waiting until it reaches that state. This will terminate any in-progress transmit or receive operation. -

ao_radio_get

+	

ao_radio_get

 	  void
 	  ao_radio_get(void);
 	

Acquires the radio mutex and then configures the radio frequency using the global radio calibration and channel values. -

ao_radio_put

+	

ao_radio_put

 	  void
 	  ao_radio_put(void);
 	

Releases the radio mutex. -

ao_radio_abort

+	

ao_radio_abort

 	  void
 	  ao_radio_abort(void);
 	

@@ -740,7 +740,7 @@ packet. The data from receiving a packet also includes the RSSI and status values supplied by the receiver. These are added after the telemetry data. -

ao_radio_send

+    

ao_radio_send

 	  void
 	  ao_radio_send(__xdata struct ao_telemetry *telemetry);
 	

@@ -749,7 +749,7 @@ telemetry mode. This function calls ao_radio_get() before sending, and ao_radio_put() afterwards, to correctly serialize access to the radio device. -

ao_radio_recv

+	

ao_radio_recv

 	  void
 	  ao_radio_recv(__xdata struct ao_radio_recv *radio);
 	

@@ -763,7 +763,7 @@

In radio direction finding mode, there's just one function to use -

ao_radio_rdf

+    

ao_radio_rdf

 	  void
 	  ao_radio_rdf(int ms);
 	

@@ -774,7 +774,7 @@ for either master or slave mode (but not both). The basic I/O functions look the same at both ends, but the internals are different, along with the initialization steps. -

ao_packet_putchar

+    

ao_packet_putchar

 	  void
 	  ao_packet_putchar(char c);
 	

@@ -784,32 +784,32 @@ transmit a packet if the output buffer is full. On the slave side, any pending data will be sent the next time the master polls for data. -

ao_packet_pollchar

+	

ao_packet_pollchar

 	  char
 	  ao_packet_pollchar(void);
 	

This returns a pending input character if available, otherwise returns AO_READ_AGAIN. On the master side, if this empties the buffer, it triggers a poll for more data. -

ao_packet_slave_start

+	

ao_packet_slave_start

 	  void
 	  ao_packet_slave_start(void);
 	

This is available only on the slave side and starts a task to listen for packet data. -

ao_packet_slave_stop

+	

ao_packet_slave_stop

 	  void
 	  ao_packet_slave_stop(void);
 	

Disables the packet slave task, stopping the radio receiver. -

ao_packet_slave_init

+	

ao_packet_slave_init

 	  void
 	  ao_packet_slave_init(void);
 	

Adds the packet stdio functions to the stdio package so that when packet slave mode is enabled, characters will get send and received through the stdio functions. -

ao_packet_master_init

+	

ao_packet_master_init

 	  void
 	  ao_packet_master_init(void);
 	

diff --git a/AltOS/doc/altos.pdf b/AltOS/doc/altos.pdf index 1236a65..38f693d 100644 Binary files a/AltOS/doc/altos.pdf and b/AltOS/doc/altos.pdf differ diff --git a/AltOS/doc/altusmetrum.html b/AltOS/doc/altusmetrum.html index f417204..1817390 100644 --- a/AltOS/doc/altusmetrum.html +++ b/AltOS/doc/altusmetrum.html @@ -1,10 +1,10 @@ -The Altus Metrum System

The Altus Metrum System

An Owner's Manual for TeleMetrum and TeleDongle Devices

Bdale Garbee

Keith Packard

Bob Finch

Anthony Towns

+The Altus Metrum System

The Altus Metrum System

An Owner's Manual for TeleMetrum and TeleDongle Devices

Bdale Garbee

Keith Packard

Bob Finch

Anthony Towns

This document is released under the terms of the Creative Commons ShareAlike 3.0 license. -

Revision History
Revision 0.824 November 2010
Updated for software version 0.8

Acknowledgements

+

Revision History
Revision 0.824 November 2010
Updated for software version 0.8

Acknowledgements

Thanks to Bob Finch, W9YA, NAR 12965, TRA 12350 for writing "The Mere-Mortals Quick Start/Usage Guide to the Altus Metrum Starter @@ -31,7 +31,7 @@ Keith NAR #88757, TRA #12200
      

-

Chapter 1. Introduction and Overview

+

Chapter 1. Introduction and Overview

Welcome to the Altus Metrum community! Our circuits and software reflect our passion for both hobby rocketry and Free Software. We hope their capabilities and performance will delight you in every way, but by @@ -54,7 +54,7 @@ NAR More products will be added to the Altus Metrum family over time, and we currently envision that this will be a single, comprehensive manual for the entire product family. -

Chapter 2. Getting Started

Table of Contents

FAQ

+

Chapter 2. Getting Started

Table of Contents

FAQ

The first thing to do after you check the inventory of parts in your "starter kit" is to charge the battery by plugging it into the corresponding socket of the TeleMetrum and then using the USB A to @@ -203,7 +203,7 @@ NAR the Log and Device menus. It has a wonderful display of the incoming flight data and I am sure you will enjoy what it has to say to you once you enable the voice output! -

FAQ

+

FAQ

The altimeter (TeleMetrum) seems to shut off when disconnected from the computer. Make sure the battery is adequately charged. Remember the unit will pull more power than the USB port can deliver before the @@ -248,7 +248,7 @@ NAR data after physically retrieving your TeleMetrum. Make sure to save the on-board data after each flight, as the current firmware will over-write any previous flight data during a new flight. -

Chapter 3. Specifications

  • +

Chapter 3. Specifications

  • Recording altimeter for model rocketry.

  • Supports dual deployment (can fire 2 ejection charges). @@ -272,7 +272,7 @@ NAR battery if needed.

  • 2.75 x 1 inch board designed to fit inside 29mm airframe coupler tube. -

Chapter 4. Handling Precautions

+

Chapter 4. Handling Precautions

TeleMetrum is a sophisticated electronic device. When handled gently and properly installed in an airframe, it will deliver impressive results. However, like all electronic devices, there are some precautions you @@ -304,7 +304,7 @@ NAR

As with all other rocketry electronics, TeleMetrum must be protected from exposure to corrosive motor exhaust and ejection charge gasses. -

Chapter 5. Hardware Overview

+

Chapter 5. Hardware Overview

TeleMetrum is a 1 inch by 2.75 inch circuit board. It was designed to fit inside coupler for 29mm airframe tubing, but using it in a tube that small in diameter may require some creativity in mounting and wiring @@ -356,7 +356,7 @@ NAR TeleMetrum with an SMA connector for the UHF antenna connection, and you can unplug the integrated GPS antenna and select an appropriate off-board GPS antenna with cable terminating in a U.FL connector. -

Chapter 6. System Operation

Firmware Modes

+

Chapter 6. System Operation

Firmware Modes

The AltOS firmware build for TeleMetrum has two fundamental modes, "idle" and "flight". Which of these modes the firmware operates in is determined by the orientation of the rocket (well, actually the @@ -404,7 +404,7 @@ NAR rickety step-ladder or hanging off the side of a launch tower with a screw-driver trying to turn on your avionics before installing igniters! -

GPS

+

GPS

TeleMetrum includes a complete GPS receiver. See a later section for a brief explanation of how GPS works that will help you understand the information in the telemetry stream. The bottom line is that @@ -423,7 +423,7 @@ NAR is turned back on, the GPS system should lock very quickly, typically long before igniter installation and return to the flight line are complete. -

Ground Testing

+

Ground Testing

An important aspect of preparing a rocket using electronic deployment for flight is ground testing the recovery system. Thanks to the bi-directional RF link central to the Altus Metrum system, @@ -446,7 +446,7 @@ NAR the board from firing a charge. The command to fire the apogee drogue charge is 'i DoIt drogue' and the command to fire the main charge is 'i DoIt main'. -

Radio Link

+

Radio Link

The chip our boards are based on incorporates an RF transceiver, but it's not a full duplex system... each end can only be transmitting or receiving at any given moment. So we had to decide how to manage the @@ -477,13 +477,13 @@ NAR the ground. We hope to fly boards to higher altitudes soon, and would of course appreciate customer feedback on performance in higher altitude flights! -

Configurable Parameters

+

Configurable Parameters

Configuring a TeleMetrum board for flight is very simple. Because we have both acceleration and pressure sensors, there is no need to set a "mach delay", for example. The few configurable parameters can all be set using a simple terminal program over the USB port or RF link via TeleDongle. -

Radio Channel

+

Radio Channel

Our firmware supports 10 channels. The default channel 0 corresponds to a center frequency of 434.550 Mhz, and channels are spaced every 100 khz. Thus, channel 1 is 434.650 Mhz, and channel 9 is 435.550 Mhz. @@ -497,7 +497,7 @@ NAR As with all 'c' sub-commands, follow this with a 'c w' to write the change to the parameter block in the on-board DataFlash chip on your TeleMetrum board if you want the change to stay in place across reboots. -

Apogee Delay

+

Apogee Delay

Apogee delay is the number of seconds after TeleMetrum detects flight apogee that the drogue charge should be fired. In most cases, this should be left at the default of 0. However, if you are flying @@ -517,7 +517,7 @@ NAR seconds later to avoid any chance of both charges firing simultaneously. We've flown several airframes this way quite happily, including Keith's successful L3 cert. -

Main Deployment Altitude

+

Main Deployment Altitude

By default, TeleMetrum will fire the main deployment charge at an elevation of 250 meters (about 820 feet) above ground. We think this is a good elevation for most airframes, but feel free to change this @@ -530,10 +530,10 @@ NAR To set the main deployment altitude, use the 'c m' command. As with all 'c' sub-commands, follow this with a 'c w' to write the change to the parameter block in the on-board DataFlash chip. -

Calibration

+

Calibration

There are only two calibrations required for a TeleMetrum board, and only one for TeleDongle. -

Radio Frequency

+

Radio Frequency

The radio frequency is synthesized from a clock based on the 48 Mhz crystal on the board. The actual frequency of this oscillator must be measured to generate a calibration constant. While our GFSK modulation @@ -557,7 +557,7 @@ NAR within a few tens of Hertz of the intended frequency. As with all 'c' sub-commands, follow this with a 'c w' to write the change to the parameter block in the on-board DataFlash chip. -

Accelerometer

+

Accelerometer

The accelerometer we use has its own 5 volt power supply and the output must be passed through a resistive voltage divider to match the input of our 3.3 volt ADC. This means that unlike the barometric @@ -596,7 +596,7 @@ NAR and use a small screwdriver or similar to short the two pins closest to the index post on the 4-pin end of the programming cable, and power up the board. It should come up in 'idle mode' (two beeps). -

Updating Device Firmware

+

Updating Device Firmware

The big conceptual thing to realize is that you have to use a TeleDongle as a programmer to update a TeleMetrum, and vice versa. Due to limited memory resources in the cc1111, we don't support @@ -611,7 +611,7 @@ NAR version from http://www.altusmetrum.org/AltOS/.

We recommend updating TeleMetrum first, before updating TeleDongle. -

Updating TeleMetrum Firmware

  1. +

    Updating TeleMetrum Firmware

    1. Find the 'programming cable' that you got as part of the starter kit, that has a red 8-pin MicroMaTch connector on one end and a red 4-pin MicroMaTch connector on the other end. @@ -654,7 +654,7 @@ NAR the version, etc.
    2. If something goes wrong, give it another try. -

    Updating TeleDongle Firmware

    +

Updating TeleDongle Firmware

Updating TeleDongle's firmware is just like updating TeleMetrum firmware, but you switch which board is the programmer and which is the programming target. @@ -715,7 +715,7 @@ NAR slightly to extract the connector. We used a locking connector on TeleMetrum to help ensure that the cabling to companion boards used in a rocket don't ever come loose accidentally in flight. -

Chapter 7. AltosUI

The AltosUI program provides a graphical user interface for interacting with the Altus Metrum product family, including TeleMetrum and TeleDongle. AltosUI can monitor telemetry data, @@ -724,7 +724,7 @@ NAR buttons, one for each major activity in the system. This manual is split into chapters, each of which documents one of the tasks provided from the top-level toolbar. -

Packet Command Mode

Controlling TeleMetrum Over The Radio Link

+

Packet Command Mode

Controlling TeleMetrum Over The Radio Link

One of the unique features of the Altus Metrum environment is the ability to create a two way command link between TeleDongle and TeleMetrum using the digital radio transceivers built into @@ -783,7 +783,7 @@ NAR TeleMetrum transmit a packet while the green LED will light up on TeleDongle while it is waiting to receive a packet from TeleMetrum. -

Monitor Flight

Receive, Record and Display Telemetry Data

+

Monitor Flight

Receive, Record and Display Telemetry Data

Selecting this item brings up a dialog box listing all of the connected TeleDongle devices. When you choose one of these, AltosUI will create a window to display telemetry data as @@ -824,7 +824,7 @@ NAR data relevant to the current state of the flight. You can select other tabs at any time. The final 'table' tab contains all of the telemetry data in one place. -

Launch Pad

+

Launch Pad

The 'Launch Pad' tab shows information used to decide when the rocket is ready for flight. The first elements include red/green indicators, if any of these is red, you'll want to evaluate @@ -861,7 +861,7 @@ NAR and altitude, averaging many reported positions to improve the accuracy of the fix.

-

Ascent

+

Ascent

This tab is shown during Boost, Fast and Coast phases. The information displayed here helps monitor the rocket as it heads towards apogee. @@ -880,7 +880,7 @@ NAR Finally, the current igniter voltages are reported as in the Launch Pad tab. This can help diagnose deployment failures caused by wiring which comes loose under high acceleration. -

Descent

+

Descent

Once the rocket has reached apogee and (we hope) activated the apogee charge, attention switches to tracking the rocket on the way back to the ground, and for dual-deploy flights, @@ -901,7 +901,7 @@ NAR Finally, the igniter voltages are reported in this tab as well, both to monitor the main charge as well as to see what the status of the apogee charge is. -

Landed

+

Landed

Once the rocket is on the ground, attention switches to recovery. While the radio signal is generally lost once the rocket is on the ground, the last reported GPS position is @@ -916,7 +916,7 @@ NAR

Finally, the maximum height, speed and acceleration reported during the flight are displayed for your admiring observers. -

Site Map

+

Site Map

When the rocket gets a GPS fix, the Site Map tab will map the rocket's position to make it easier for you to locate the rocket, both while it is in the air, and when it has landed. The @@ -932,7 +932,7 @@ NAR and are cached for reuse. If map images cannot be downloaded, the rocket's path will be traced on a dark grey background instead. -

Save Flight Data

+

Save Flight Data

TeleMetrum records flight data to its internal flash memory. This data is recorded at a much higher rate than the telemetry system can handle, and is not subject to radio drop-outs. As @@ -951,7 +951,7 @@ NAR The filename for the data is computed automatically from the recorded flight date, TeleMetrum serial number and flight number information. -

Replay Flight

+

Replay Flight

Select this button and you are prompted to select a flight record file, either a .telem file recording telemetry data or a .eeprom file containing flight data saved from the TeleMetrum @@ -960,7 +960,7 @@ NAR Once a flight record is selected, the flight monitor interface is displayed and the flight is re-enacted in real time. Check the Monitor Flight chapter above to learn how this window operates. -

Graph Data

+

Graph Data

Select this button and you are prompted to select a flight record file, either a .telem file recording telemetry data or a .eeprom file containing flight data saved from the TeleMetrum @@ -982,7 +982,7 @@ NAR and will also often have significant amounts of data received while the rocket was waiting on the pad. Use saved flight data for graphing where possible. -

Export Data

+

Export Data

This tool takes the raw data files and makes them available for external analysis. When you select this button, you are prompted to select a flight data file (either .eeprom or .telem will do, remember that @@ -990,7 +990,7 @@ NAR data). Next, a second dialog appears which is used to select where to write the resulting file. It has a selector to choose between CSV and KML file formats. -

Comma Separated Value Format

+

Comma Separated Value Format

This is a text file containing the data in a form suitable for import into a spreadsheet or other external data analysis tool. The first few lines of the file contain the version and @@ -1004,12 +1004,12 @@ NAR the sensor values are converted to standard units, with the barometric data reported in both pressure, altitude and height above pad units. -

Keyhole Markup Language (for Google Earth)

+

Keyhole Markup Language (for Google Earth)

This is the format used by Googleearth to provide an overlay within that application. With this, you can use Googleearth to see the whole flight path in 3D. -

Configure TeleMetrum

+

Configure TeleMetrum

Select this button and then select either a TeleMetrum or TeleDongle Device from the list provided. Selecting a TeleDongle device will use Packet Comamnd Mode to configure remote @@ -1038,14 +1038,14 @@ NAR lost.

The rest of the dialog contains the parameters to be configured. -

Main Deploy Altitude

+

Main Deploy Altitude

This sets the altitude (above the recorded pad altitude) at which the 'main' igniter will fire. The drop-down menu shows some common values, but you can edit the text directly and choose whatever you like. If the apogee charge fires below this altitude, then the main charge will fire two seconds after the apogee charge fires. -

Apogee Delay

+

Apogee Delay

When flying redundant electronics, it's often important to ensure that multiple apogee charges don't fire at precisely the same time as that can overpressurize the apogee deployment @@ -1053,24 +1053,24 @@ NAR Delay parameter tells the flight computer to fire the apogee charge a certain number of seconds after apogee has been detected. -

Radio Channel

+

Radio Channel

This configures which of the 10 radio channels to use for both telemetry and packet command mode. Note that if you set this value via packet command mode, you will have to reconfigure the TeleDongle channel before you will be able to use packet command mode again. -

Radio Calibration

+

Radio Calibration

The radios in every Altus Metrum device are calibrated at the factory to ensure that they transmit and receive on the specified frequency for each channel. You can adjust that calibration by changing this value. To change the TeleDongle's calibration, you must reprogram the unit completely. -

Callsign

+

Callsign

This sets the callsign included in each telemetry packet. Set this as needed to conform to your local radio regulations. -

Configure AltosUI

+

Configure AltosUI

This button presents a dialog so that you can configure the AltosUI global settings. -

Voice Settings

+

Voice Settings

AltosUI provides voice annoucements during flight so that you can keep your eyes on the sky and still get information about the current flight status. However, sometimes you don't want @@ -1079,7 +1079,7 @@ NAR Test Voice—Plays a short message allowing you to verify that the audio systme is working and the volume settings are reasonable -

Log Directory

+

Log Directory

AltosUI logs all telemetry data and saves all TeleMetrum flash data to this directory. This directory is also used as the staring point when selecting data files for display or export. @@ -1087,14 +1087,14 @@ NAR Click on the directory name to bring up a directory choosing dialog, select a new directory and click 'Select Directory' to change where AltosUI reads and writes data files. -

Callsign

+

Callsign

This value is used in command packet mode and is transmitted in each packet sent from TeleDongle and received from TeleMetrum. It is not used in telemetry mode as that transmits packets only from TeleMetrum to TeleDongle. Configure this with the AltosUI operators callsign as needed to comply with your local radio regulations. -

Flash Image

+

Flash Image

This reprograms any Altus Metrum device by using a TeleMetrum or TeleDongle as a programming dongle. Please read the directions for connecting the programming cable in the main TeleMetrum @@ -1124,7 +1124,7 @@ NAR will have to unplug it and then plug it back in for the USB connection to reset so that you can communicate with the device again. -

Fire Igniter

+

Fire Igniter

This activates the igniter circuits in TeleMetrum to help test recovery systems deployment. Because this command can operate over the Packet Command Link, you can prepare the rocket as @@ -1144,11 +1144,11 @@ NAR you have 10 seconds to press the 'Fire' button or the system will deactivate, at which point you start over again at selecting the desired igniter. -

Chapter 8. Using Altus Metrum Products

Being Legal

+

Chapter 8. Using Altus Metrum Products

Being Legal

First off, in the US, you need an amateur radio license or other authorization to legally operate the radio transmitters that are part of our products. -

In the Rocket

+

In the Rocket

In the rocket itself, you just need a TeleMetrum board and a LiPo rechargeable battery. An 860mAh battery weighs less than a 9V alkaline battery, and will run a TeleMetrum for hours. @@ -1158,7 +1158,7 @@ NAR which is opaque to RF signals, you may choose to have an SMA connector installed so that you can run a coaxial cable to an antenna mounted elsewhere in the rocket. -

On the Ground

+

On the Ground

To receive the data stream from the rocket, you need an antenna and short feedline connected to one of our TeleDongle units. The TeleDongle in turn plugs directly into the USB port on a notebook @@ -1209,7 +1209,7 @@ NAR The 440-3 and 440-5 are both good choices for finding a TeleMetrum-equipped rocket when used with a suitable 70cm HT. -

Data Analysis

+

Data Analysis

Our software makes it easy to log the data from each flight, both the telemetry received over the RF link during the flight itself, and the more complete data log recorded in the DataFlash memory on the TeleMetrum @@ -1224,7 +1224,7 @@ NAR Our ultimate goal is to emit a set of files for each flight that can be published as a web page per flight, or just viewed on your local disk with a web browser. -

Future Plans

+

Future Plans

In the future, we intend to offer "companion boards" for the rocket that will plug in to TeleMetrum to collect additional data, provide more pyro channels, and so forth. A reference design for a companion board will be documented diff --git a/AltOS/doc/altusmetrum.pdf b/AltOS/doc/altusmetrum.pdf index 2eb1ff1..dbaf39b 100644 Binary files a/AltOS/doc/altusmetrum.pdf and b/AltOS/doc/altusmetrum.pdf differ