From: Bdale Garbee Date: Fri, 22 Dec 2017 02:50:56 +0000 (-0700) Subject: update docs X-Git-Url: https://git.gag.com/?a=commitdiff_plain;h=e28ff195f95038471b14a8d1dc641b65ea365f5a;p=web%2Faltusmetrum update docs --- diff --git a/AltOS/doc/altos.html b/AltOS/doc/altos.html index 421fb2e..7ca6a09 100644 --- a/AltOS/doc/altos.html +++ b/AltOS/doc/altos.html @@ -1,1004 +1,635 @@ -AltOS

AltOS

Altos Metrum Operating System

Keith Packard

Copyright © 2010 Keith Packard

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

Revision History
Revision 1.105 November 2012
Portable version
Revision 0.122 November 2010
Initial content

Table of Contents

1. Overview
2. AltOS Porting Layer
1. Low-level CPU operations
1.1. ao_arch_block_interrupts/ao_arch_release_interrupts
1.2. ao_arch_save_regs, ao_arch_save_stack, - ao_arch_restore_stack
1.3. ao_arch_wait_interupt
2. GPIO operations
2.1. GPIO setup
2.2. Reading and writing GPIO pins
3. Programming the 8051 with SDCC
1. 8051 memory spaces
1.1. __data
1.2. __idata
1.3. __xdata
1.4. __pdata
1.5. __code
1.6. __bit
1.7. __sfr, __sfr16, __sfr32, __sbit
2. Function calls on the 8051
2.1. __reentrant functions
2.2. Non __reentrant functions
2.3. __interrupt functions
2.4. __critical functions and statements
4. Task functions
1. ao_add_task
2. ao_exit
3. ao_sleep
4. ao_wakeup
5. ao_alarm
6. ao_start_scheduler
7. ao_clock_init
5. Timer Functions
1. ao_time
2. ao_delay
3. ao_timer_set_adc_interval
4. ao_timer_init
6. AltOS Mutexes
1. ao_mutex_get
2. ao_mutex_put
7. DMA engine
1. CC1111 DMA Engine
1.1. ao_dma_alloc
1.2. ao_dma_set_transfer
1.3. ao_dma_start
1.4. ao_dma_trigger
1.5. ao_dma_abort
2. STM32L DMA Engine
2.1. ao_dma_alloc
2.2. ao_dma_set_transfer
2.3. ao_dma_set_isr
2.4. ao_dma_start
2.5. ao_dma_done_transfer
2.6. ao_dma_abort
8. Stdio interface
1. putchar
2. getchar
3. flush
4. ao_add_stdio
9. Command line interface
1. ao_cmd_register
2. ao_cmd_lex
3. ao_cmd_put16
4. ao_cmd_put8
5. ao_cmd_white
6. ao_cmd_hex
7. ao_cmd_decimal
8. ao_match_word
9. ao_cmd_init
10. USB target device
1. ao_usb_flush
2. ao_usb_putchar
3. ao_usb_pollchar
4. ao_usb_getchar
5. ao_usb_disable
6. ao_usb_enable
7. ao_usb_init
11. Serial peripherals
1. ao_serial_getchar
2. ao_serial_putchar
3. ao_serial_drain
4. ao_serial_set_speed
5. ao_serial_init
12. CC1111 Radio peripheral
1. Radio Introduction
2. ao_radio_set_telemetry
3. ao_radio_set_packet
4. ao_radio_set_rdf
5. ao_radio_idle
6. ao_radio_get
7. ao_radio_put
8. ao_radio_abort
9. Radio Telemetry
9.1. ao_radio_send
9.2. ao_radio_recv
10. Radio Direction Finding
10.1. ao_radio_rdf
11. Radio Packet Mode
11.1. ao_packet_putchar
11.2. ao_packet_pollchar
11.3. ao_packet_slave_start
11.4. ao_packet_slave_stop
11.5. ao_packet_slave_init
11.6. ao_packet_master_init

Chapter 1. Overview

- AltOS is a operating system built for a variety of - microcontrollers used in Altus Metrum devices. It has a simple - porting layer for each CPU while providing a convenient - operating enviroment for the developer. AltOS currently - supports three different CPUs: -

  • - STM32L series from ST Microelectronics. This ARM Cortex-M3 - based microcontroller offers low power consumption and a - wide variety of built-in peripherals. Altus Metrum uses - this in the TeleMega, MegaDongle and TeleLCO projects. -

  • - CC1111 from Texas Instruments. This device includes a - fabulous 10mW digital RF transceiver along with an - 8051-compatible processor core and a range of - peripherals. This is used in the TeleMetrum, TeleMini, - TeleDongle and TeleFire projects which share the need for - a small microcontroller and an RF interface. -

  • - ATmega32U4 from Atmel. This 8-bit AVR microcontroller is - one of the many used to create Arduino boards. The 32U4 - includes a USB interface, making it easy to connect to - other computers. Altus Metrum used this in prototypes of - the TeleScience and TelePyro boards; those have been - switched to the STM32L which is more capable and cheaper. -

- Among the features of AltOS are: -

  • Multi-tasking. While microcontrollers often don't - provide separate address spaces, it's often easier to write - code that operates in separate threads instead of tying - everything into one giant event loop. -

  • Non-preemptive. This increases latency for thread - switching but reduces the number of places where context - switching can occur. It also simplifies the operating system - design somewhat. Nothing in the target system (rocket flight - control) has tight timing requirements, and so this seems like - a reasonable compromise. -

  • Sleep/wakeup scheduling. Taken directly from ancient - Unix designs, these two provide the fundemental scheduling - primitive within AltOS. -

  • Mutexes. As a locking primitive, mutexes are easier to - use than semaphores, at least in my experience. -

  • Timers. Tasks can set an alarm which will abort any - pending sleep, allowing operations to time-out instead of - blocking forever. -

-

- The device drivers and other subsystems in AltOS are - conventionally enabled by invoking their _init() function from - the 'main' function before that calls - ao_start_scheduler(). These functions initialize the pin - assignments, add various commands to the command processor and - may add tasks to the scheduler to handle the device. A typical - main program, thus, looks like: - 

-	void
-	main(void)
-	{
-	        ao_clock_init();
+
+AltOS
AltOS
Altos Metrum Operating System
Keith Packard
Copyright © 2012 Keith Packard

+    This document is released under the terms of the
+    
+      Creative Commons ShareAlike 3.0
+    
+    license.
+  
Table of Contents
1. Overview
2. AltOS Porting Layer
2.1. Low-level CPU operations
2.1.1. ao_arch_block_interrupts/ao_arch_release_interrupts
2.1.2. ao_arch_save_regs, ao_arch_save_stack, ao_arch_restore_stack
2.1.3. ao_arch_wait_interupt
2.2. GPIO operations
2.2.1. GPIO setup
2.2.2. Reading and writing GPIO pins
2.3. 8051 memory spaces
2.3.1. __data
2.3.2. __idata
2.3.3. __xdata
2.3.4. __pdata
2.3.5. __code
2.3.6. __bit
2.3.7. sfr, sfr16, sfr32, sbit
2.4. Function calls on the 8051
2.4.1. __reentrant functions
2.4.2. Non __reentrant functions
2.4.3. __interrupt functions
2.4.4. __critical functions and statements
3. Task functions
3.1. ao_add_task
3.2. ao_exit
3.3. ao_sleep
3.4. ao_wakeup
3.5. ao_alarm
3.6. ao_start_scheduler
3.7. ao_clock_init
4. Timer Functions
4.1. ao_time
4.2. ao_delay
4.3. ao_timer_set_adc_interval
4.4. ao_timer_init
5. AltOS Mutexes
5.1. ao_mutex_get
5.2. ao_mutex_put
6. DMA engine
6.1. CC1111 DMA Engine
6.1.1. ao_dma_alloc
6.1.2. ao_dma_set_transfer
6.1.3. ao_dma_start
6.1.4. ao_dma_trigger
6.1.5. ao_dma_abort
6.2. STM32L DMA Engine
6.2.1. ao_dma_alloc
6.2.2. ao_dma_set_transfer
6.2.3. ao_dma_set_isr
6.2.4. ao_dma_start
6.2.5. ao_dma_done_transfer
6.2.6. ao_dma_abort
7. Stdio interface
7.1. putchar
7.2. getchar
7.3. flush
7.4. ao_add_stdio
8. Command line interface
8.1. ao_cmd_register
8.2. ao_cmd_lex
8.3. ao_cmd_put16
8.4. ao_cmd_put8
8.5. ao_cmd_white
8.6. ao_cmd_hex
8.7. ao_cmd_decimal
8.8. ao_match_word
8.9. ao_cmd_init
9. USB target device
9.1. ao_usb_flush
9.2. ao_usb_putchar
9.3. ao_usb_pollchar
9.4. ao_usb_getchar
9.5. ao_usb_disable
9.6. ao_usb_enable
9.7. ao_usb_init
10. Serial peripherals
10.1. ao_serial_getchar
10.2. ao_serial_putchar
10.3. ao_serial_drain
10.4. ao_serial_set_speed
10.5. ao_serial_init
11. CC1111/CC1120/CC1200 Radio peripheral
11.1. Radio Introduction
11.2. ao_radio_set_telemetry
11.3. ao_radio_set_packet
11.4. ao_radio_set_rdf
11.5. ao_radio_idle
11.6. ao_radio_get
11.7. ao_radio_put
11.8. ao_radio_abort
11.9. Radio Telemetry
11.9.1. ao_radio_send
11.9.2. ao_radio_recv
11.10. Radio Direction Finding
11.10.1. ao_radio_rdf
11.11. Radio Packet Mode
11.11.1. ao_packet_putchar
11.11.2. ao_packet_pollchar
11.11.3. ao_packet_slave_start
11.11.4. ao_packet_slave_stop
11.11.5. ao_packet_slave_init
11.11.6. ao_packet_master_init
Chapter 1. Overview
AltOS is a operating system built for a variety of
+microcontrollers used in Altus Metrum devices. It has a simple
+porting layer for each CPU while providing a convenient
+operating enviroment for the developer. AltOS currently
+supports three different CPUs:
  • 
+STM32L series from ST Microelectronics. This ARM Cortex-M3
+based microcontroller offers low power consumption and a
+wide variety of built-in peripherals. Altus Metrum uses this
+in the TeleMega, MegaDongle and TeleLCO projects.
+
  • 
+CC1111 from Texas Instruments. This device includes a
+fabulous 10mW digital RF transceiver along with an
+8051-compatible processor core and a range of
+peripherals. This is used in the TeleMetrum, TeleMini,
+TeleDongle and TeleFire projects which share the need for a
+small microcontroller and an RF interface.
+
  • 
+ATmega32U4 from Atmel. This 8-bit AVR microcontroller is one
+of the many used to create Arduino boards. The 32U4 includes
+a USB interface, making it easy to connect to other
+computers. Altus Metrum used this in prototypes of the
+TeleScience and TelePyro boards; those have been switched to
+the STM32L which is more capable and cheaper.
+
Among the features of AltOS are:
  • 
+Multi-tasking. While microcontrollers often don’t
+provide separate address spaces, it’s often easier to write
+code that operates in separate threads instead of tying
+everything into one giant event loop.
+
  • 
+Non-preemptive. This increases latency for thread
+switching but reduces the number of places where context
+switching can occur. It also simplifies the operating system
+design somewhat. Nothing in the target system (rocket flight
+control) has tight timing requirements, and so this seems like
+a reasonable compromise.
+
  • 
+Sleep/wakeup scheduling. Taken directly from ancient
+Unix designs, these two provide the fundemental scheduling
+primitive within AltOS.
+
  • 
+Mutexes. As a locking primitive, mutexes are easier to
+use than semaphores, at least in my experience.
+
  • 
+Timers. Tasks can set an alarm which will abort any
+pending sleep, allowing operations to time-out instead of
+blocking forever.
+
The device drivers and other subsystems in AltOS are
+conventionally enabled by invoking their _init() function from
+the main function before that calls
+ao_start_scheduler(). These functions initialize the pin
+assignments, add various commands to the command processor and
+may add tasks to the scheduler to handle the device. A typical
+main program, thus, looks like:
void
+main(void)
+{
+        ao_clock_init();
 
-	        /* Turn on the LED until the system is stable */
-	        ao_led_init(LEDS_AVAILABLE);
-	        ao_led_on(AO_LED_RED);
-	        ao_timer_init();
-	        ao_cmd_init();
-	        ao_usb_init();
-	        ao_monitor_init(AO_LED_GREEN, TRUE);
-	        ao_rssi_init(AO_LED_RED);
-	        ao_radio_init();
-	        ao_packet_slave_init();
-	        ao_packet_master_init();
-	        #if HAS_DBG
-	        ao_dbg_init();
-	        #endif
-	        ao_config_init();
-	        ao_start_scheduler();
-	}
-      

-      As you can see, a long sequence of subsystems are initialized
-      and then the scheduler is started.
-    
Chapter 2. AltOS Porting Layer
Table of Contents
1. Low-level CPU operations
1.1. ao_arch_block_interrupts/ao_arch_release_interrupts
1.2. ao_arch_save_regs, ao_arch_save_stack,
-	ao_arch_restore_stack
1.3. ao_arch_wait_interupt
2. GPIO operations
2.1. GPIO setup
2.2. Reading and writing GPIO pins

-      AltOS provides a CPU-independent interface to various common
-      microcontroller subsystems, including GPIO pins, interrupts,
-      SPI, I2C, USB and asynchronous serial interfaces. By making
-      these CPU-independent, device drivers, generic OS and
-      application code can all be written that work on any supported
-      CPU. Many of the architecture abstraction interfaces are
-      prefixed with ao_arch.
-    
1. Low-level CPU operations

-	These primitive operations provide the abstraction needed to
-	run the multi-tasking framework while providing reliable
-	interrupt delivery.
-      
1.1. ao_arch_block_interrupts/ao_arch_release_interrupts
-	  static inline void
-	  ao_arch_block_interrupts(void);
-	  
-	  static inline void
-	  ao_arch_release_interrupts(void);
-	

-	  These disable/enable interrupt delivery, they may not
-	  discard any interrupts. Use these for sections of code that
-	  must be atomic with respect to any code run from an
-	  interrupt handler.
-	
1.2. ao_arch_save_regs, ao_arch_save_stack,
-	ao_arch_restore_stack
-	  static inline void
-	  ao_arch_save_regs(void);
+        /* Turn on the LED until the system is stable */
+        ao_led_init(LEDS_AVAILABLE);
+        ao_led_on(AO_LED_RED);
+        ao_timer_init();
+        ao_cmd_init();
+        ao_usb_init();
+        ao_monitor_init(AO_LED_GREEN, TRUE);
+        ao_rssi_init(AO_LED_RED);
+        ao_radio_init();
+        ao_packet_slave_init();
+        ao_packet_master_init();
+#if HAS_DBG
+        ao_dbg_init();
+#endif
+        ao_config_init();
+        ao_start_scheduler();
+}
As you can see, a long sequence of subsystems are initialized
+and then the scheduler is started.
Chapter 2. AltOS Porting Layer
AltOS provides a CPU-independent interface to various common
+microcontroller subsystems, including GPIO pins, interrupts,
+SPI, I2C, USB and asynchronous serial interfaces. By making
+these CPU-independent, device drivers, generic OS and
+application code can all be written that work on any supported
+CPU. Many of the architecture abstraction interfaces are
+prefixed with ao_arch.
2.1. Low-level CPU operations
These primitive operations provide the abstraction needed to
+run the multi-tasking framework while providing reliable
+interrupt delivery.
2.1.1. ao_arch_block_interrupts/ao_arch_release_interrupts
static inline void
+ao_arch_block_interrupts(void);
 
-	  static inline void
-	  ao_arch_save_stack(void);
+static inline void
+ao_arch_release_interrupts(void);
These disable/enable interrupt delivery, they may not
+discard any interrupts. Use these for sections of code that
+must be atomic with respect to any code run from an
+interrupt handler.
2.1.2. ao_arch_save_regs, ao_arch_save_stack, ao_arch_restore_stack
static inline void
+ao_arch_save_regs(void);
 
-	  static inline void
-	  ao_arch_restore_stack(void);
-	

-	  These provide all of the support needed to switch between
-	  tasks.. ao_arch_save_regs must save all CPU registers to the
-	  current stack, including the interrupt enable
-	  state. ao_arch_save_stack records the current stack location
-	  in the current ao_task structure. ao_arch_restore_stack
-	  switches back to the saved stack, restores all registers and
-	  branches to the saved return address.
-	
1.3. ao_arch_wait_interupt
-	  #define ao_arch_wait_interrupt()
-	

-	  This stops the CPU, leaving clocks and interrupts
-	  enabled. When an interrupt is received, this must wake up
-	  and handle the interrupt. ao_arch_wait_interrupt is entered
-	  with interrupts disabled to ensure that there is no gap
-	  between determining that no task wants to run and idling the
-	  CPU. It must sleep the CPU, process interrupts and then
-	  disable interrupts again. If the CPU doesn't have any
-	  reduced power mode, this must at the least allow pending
-	  interrupts to be processed.
-	
2. GPIO operations

-	These functions provide an abstract interface to configure and
-	manipulate GPIO pins.
-      
2.1. GPIO setup

-	  These macros may be invoked at system initialization time to
-	  configure pins as needed for system operation. One tricky
-	  aspect is that some chips provide direct access to specific
-	  GPIO pins while others only provide access to a whole
-	  register full of pins. To support this, the GPIO macros
-	  provide both port+bit and pin arguments. Simply define the
-	  arguments needed for the target platform and leave the
-	  others undefined.
-	
2.1.1. ao_enable_output
-	    #define ao_enable_output(port, bit, pin, value)
-	  

-	    Set the specified port+bit (also called 'pin') for output,
-	    initializing to the specified value. The macro must avoid
-	    driving the pin with the opposite value if at all
-	    possible.
-	  
2.1.2. ao_enable_input
-	    #define ao_enable_input(port, bit, mode)
-	  

-	    Sets the specified port/bit to be an input pin. 'mode' is
-	    a combination of one or more of the following. Note that
-	    some platforms may not support the desired mode. In that
-	    case, the value will not be defined so that the program
-	    will fail to compile.
-	    
  • 
-		AO_EXTI_MODE_PULL_UP. Apply a pull-up to the pin; a
-		disconnected pin will read as 1.
-
  • 
-		AO_EXTI_MODE_PULL_DOWN. Apply a pull-down to the pin;
-		a disconnected pin will read as 0.
-
  • 
-		0. Don't apply either a pull-up or pull-down. A
-		disconnected pin will read an undetermined value.
-

-	  
2.2. Reading and writing GPIO pins

-	  These macros read and write individual GPIO pins.
-	
2.2.1. ao_gpio_set
-	    #define ao_gpio_set(port, bit, pin, value)
-	  

-	    Sets the specified port/bit or pin to the indicated value
-	  
2.2.2. ao_gpio_get
-	    #define ao_gpio_get(port, bit, pin)
-	  

-	    Returns either 1 or 0 depending on whether the input to
-	    the pin is high or low.
-	  
Chapter 3. Programming the 8051 with SDCC
Table of Contents
1. 8051 memory spaces
1.1. __data
1.2. __idata
1.3. __xdata
1.4. __pdata
1.5. __code
1.6. __bit
1.7. __sfr, __sfr16, __sfr32, __sbit
2. Function calls on the 8051
2.1. __reentrant functions
2.2. Non __reentrant functions
2.3. __interrupt functions
2.4. __critical functions and statements

-      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
-      spaces. Furthermore, accessing stack variables is slow, and the
-      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.
-    

-      When built on other architectures, the various SDCC-specific
-      symbols are #defined as empty strings so they don't affect the compiler.
-    
1. 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
-	space, and so it's possible to convert any address into a
-	unique 16-bit address. SDCC doesn't know this, and so a
-	'global' address to SDCC consumes 3 bytes of memory, 1 byte as
-	a tag indicating the memory space and 2 bytes of offset within
-	that space. AltOS avoids these 3-byte addresses as much as
-	possible; using them involves a function call per byte
-	access. The result is that nearly every variable declaration
-	is decorated with a memory space identifier which clutters the
-	code but makes the resulting code far smaller and more
-	efficient.
-      
1.1. __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
-	  confuse things further, the 8 general registers in the
-	  CPU are actually stored in this memory space. There are
-	  magic instructions to 'bank switch' among 4 banks of
-	  these registers located at 0x00 - 0x1F. AltOS uses only
-	  the first bank at 0x00 - 0x07, leaving the other 24
-	  bytes available for other data.
-	
1.2. __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.
-	
1.3. __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.
-	
1.4. __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.
-	
1.5. __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.
-	
1.6. __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.
-	
1.7. __sfr, __sfr16, __sfr32, __sbit

-	  Access to physical registers in the device use this mode
-	  which declares the variable name, its type and the
-	  address it lives at. No memory is allocated for these
-	  variables.
-	
2. 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
-	memory. Just like fortran. This makes these functions
-	non-reentrant, and also consume space for parameters and
-	locals even when they are not running. The benefit is smaller
-	code and faster execution.
-      
2.1. __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
-	  variables get allocated on the stack. This ensures that
-	  these values are not overwritten by another invocation of
-	  the function.
-	

-	  Functions which use significant amounts of space for
-	  arguments and/or local variables and which are not often
-	  invoked can also be marked as __reentrant. The resulting
-	  code will be larger, but the savings in memory are
-	  frequently worthwhile.
-	
2.2. 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
-	  consuming __data space for infrequently used variables in
-	  frequently used functions.
-	

-	  All library functions called by SDCC, including functions
-	  for multiplying and dividing large data types, are
-	  non-reentrant. Because of this, interrupt handlers must not
-	  invoke any library functions, including the multiply and
-	  divide code.
-	
2.3. __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.
-	
2.4. __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
-	  execution. Individual statements may also be marked as
-	  __critical which blocks interrupts during the execution of
-	  that statement. Keeping critical sections as short as
-	  possible is key to ensuring that interrupts are handled as
-	  quickly as possible. AltOS doesn't use this form in shared
-	  code as other compilers wouldn't know what to do. Use
-	  ao_arch_block_interrupts and ao_arch_release_interrupts instead.
-	
Chapter 4. Task functions
Table of Contents
1. ao_add_task
2. ao_exit
3. ao_sleep
4. ao_wakeup
5. ao_alarm
6. ao_start_scheduler
7. ao_clock_init

-      This chapter documents how to create, destroy and schedule AltOS tasks.
-    
1. ao_add_task
-	void
-	ao_add_task(__xdata struct ao_task * task,
-	            void (*start)(void),
-	            __code char *name);
-      

-	This initializes the statically allocated task structure,
-	assigns a name to it (not used for anything but the task
-	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.
-      
2. ao_exit
-	void
-	ao_exit(void)
-      

-	This terminates the current task.
-      
3. ao_sleep
-	void
-	ao_sleep(__xdata void *wchan)
-      

-	This suspends the current task until 'wchan' is signaled
-	by ao_wakeup, or until the timeout, set by ao_alarm,
-	fires. If 'wchan' is signaled, ao_sleep returns 0, otherwise
-	it returns 1. This is the only way to switch to another task.
-      

-	Because ao_wakeup wakes every task waiting on a particular
-	location, ao_sleep should be used in a loop that first checks
-	the desired condition, blocks in ao_sleep and then rechecks
-	until the condition is satisfied. If the location may be
-	signaled from an interrupt handler, the code will need to
-	block interrupts around the block of code. Here's a complete
-	example:
-	
-	  ao_arch_block_interrupts();
-	  while (!ao_radio_done)
-	          ao_sleep(&ao_radio_done);
-	  ao_arch_release_interrupts();
-	

-      
4. ao_wakeup
-	void
-	ao_wakeup(__xdata void *wchan)
-      

-	Wake all tasks blocked on 'wchan'. This makes them
-	available to be run again, but does not actually switch
-	to another task. Here's an example of using this:
-	
-	  if (RFIF & RFIF_IM_DONE) {
-	          ao_radio_done = 1;
-	          ao_wakeup(&ao_radio_done);
-	          RFIF &= ~RFIF_IM_DONE;
-	  }
-	

-	Note that this need not block interrupts as the ao_sleep block
-	can only be run from normal mode, and so this sequence can
-	never be interrupted with execution of the other sequence.
-      
5. ao_alarm
-	void
-	ao_alarm(uint16_t delay);
+static inline void
+ao_arch_save_stack(void);
 
-	void
-	ao_clear_alarm(void);
-      

-	Schedules an alarm to fire in at least 'delay' ticks. If the
-	task is asleep when the alarm fires, it will wakeup and
-	ao_sleep will return 1. ao_clear_alarm resets any pending
-	alarm so that it doesn't fire at some arbitrary point in the
-	future.
-	
-	  ao_alarm(ao_packet_master_delay);
-	  ao_arch_block_interrupts();
-	  while (!ao_radio_dma_done)
-	          if (ao_sleep(&ao_radio_dma_done) != 0)
-	                  ao_radio_abort();
-	  ao_arch_release_interrupts();
-	  ao_clear_alarm();
-	

-	In this example, a timeout is set before waiting for
-	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.
-      
6. 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.
-      
7. ao_clock_init
-	void
-	ao_clock_init(void);
-      

-	This initializes the main CPU clock and switches to it.
-      
Chapter 5. Timer Functions
Table of Contents
1. ao_time
2. ao_delay
3. ao_timer_set_adc_interval
4. ao_timer_init

-      AltOS sets up one of the CPU 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
-      waiting for that time to pass, then fires off the sensors to
-      collect current data readings. Doing this from the ISR ensures
-      that the values are sampled at a regular rate, independent
-      of any scheduling jitter.
-    
1. 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.
-      
2. ao_delay
-	void
-	ao_delay(uint16_t ticks);
-      

-	Suspend the current task for at least 'ticks' clock units.
-      
3. 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.
-      
4. ao_timer_init
-	void
-	ao_timer_init(void)
-      

-	This turns on the 100Hz tick. It is required for any of the
-	time-based functions to work. It should be called by 'main'
-	before ao_start_scheduler.
-      
Chapter 6. AltOS Mutexes
Table of Contents
1. ao_mutex_get
2. 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.
-    
1. ao_mutex_get
-	void
-	ao_mutex_get(__xdata uint8_t *mutex);
-      

-	Acquires the specified mutex, blocking if the mutex is
-	owned by another task.
-      
2. ao_mutex_put
-	void
-	ao_mutex_put(__xdata uint8_t *mutex);
-      

-	Releases the specified mutex, waking up all tasks waiting
-	for it.
-      
Chapter 7. DMA engine
Table of Contents
1. CC1111 DMA Engine
1.1. ao_dma_alloc
1.2. ao_dma_set_transfer
1.3. ao_dma_start
1.4. ao_dma_trigger
1.5. ao_dma_abort
2. STM32L DMA Engine
2.1. ao_dma_alloc
2.2. ao_dma_set_transfer
2.3. ao_dma_set_isr
2.4. ao_dma_start
2.5. ao_dma_done_transfer
2.6. ao_dma_abort

-      The CC1111 and STM32L both contain a useful bit of extra
-      hardware in the form of a number of programmable DMA
-      engines. They can be configured to copy data in memory, or
-      between memory and devices (or even between two devices). AltOS
-      exposes a general interface to this hardware and uses it to
-      handle both internal and external devices.
-    

-      Because the CC1111 and STM32L DMA engines are different, the
-      interface to them is also different. As the DMA engines are
-      currently used to implement platform-specific drivers, this
-      isn't yet a problem.
-    

-      Code using a DMA engine should allocate one at startup
-      time. There is no provision to free them, and if you run out,
-      AltOS will simply panic.
-    

-      During operation, the DMA engine is initialized with the
-      transfer parameters. Then it is started, at which point it
-      awaits a suitable event to start copying data. When copying data
-      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.
-    
1. CC1111 DMA Engine
1.1. ao_dma_alloc
-	  uint8_t
-	  ao_dma_alloc(__xdata uint8_t *done)
-	

-	  Allocate a DMA engine, returning the identifier.  'done' is
-	  cleared when the DMA is started, and then receives the
-	  AO_DMA_DONE bit on a successful transfer or the
-	  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.
-	
1.2. ao_dma_set_transfer
-	  void
-	  ao_dma_set_transfer(uint8_t id,
-	  void __xdata *srcaddr,
-	  void __xdata *dstaddr,
-	  uint16_t count,
-	  uint8_t cfg0,
-	  uint8_t cfg1)
-	

-	  Initializes the specified dma engine to copy data
-	  from 'srcaddr' to 'dstaddr' for 'count' units. cfg0 and
-	  cfg1 are values directly out of the CC1111 documentation
-	  and tell the DMA engine what the transfer unit size,
-	  direction and step are.
-	
1.3. 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.
-	
1.4. ao_dma_trigger
-	  void
-	  ao_dma_trigger(uint8_t id)
-	

-	  Trigger the specified DMA engine to start copying data.
-	
1.5. ao_dma_abort
-	  void
-	  ao_dma_abort(uint8_t id)
-	

-	  Terminate any in-progress DMA transaction, marking its
-	  'done' variable with the AO_DMA_ABORTED bit.
-	
2. STM32L DMA Engine
2.1. ao_dma_alloc
-	  uint8_t ao_dma_done[];
+static inline void
+ao_arch_restore_stack(void);
These provide all of the support needed to switch
+between tasks.. ao_arch_save_regs must save all CPU
+registers to the current stack, including the
+interrupt enable state. ao_arch_save_stack records the
+current stack location in the current ao_task
+structure. ao_arch_restore_stack switches back to the
+saved stack, restores all registers and branches to
+the saved return address.
2.1.3. ao_arch_wait_interupt
#define ao_arch_wait_interrupt()
This stops the CPU, leaving clocks and interrupts
+enabled. When an interrupt is received, this must wake up
+and handle the interrupt. ao_arch_wait_interrupt is entered
+with interrupts disabled to ensure that there is no gap
+between determining that no task wants to run and idling the
+CPU. It must sleep the CPU, process interrupts and then
+disable interrupts again. If the CPU doesn’t have any
+reduced power mode, this must at the least allow pending
+interrupts to be processed.
2.2. GPIO operations
These functions provide an abstract interface to configure and
+manipulate GPIO pins.
2.2.1. GPIO setup
These macros may be invoked at system
+initialization time to configure pins as
+needed for system operation. One tricky aspect
+is that some chips provide direct access to
+specific GPIO pins while others only provide
+access to a whole register full of pins. To
+support this, the GPIO macros provide both
+port+bit and pin arguments. Simply define the
+arguments needed for the target platform and
+leave the others undefined.
ao_enable_output
#define ao_enable_output(port, bit, pin, value)
Set the specified port+bit (also called pin)
+for output, initializing to the specified
+value. The macro must avoid driving the pin
+with the opposite value if at all possible.
ao_enable_input
#define ao_enable_input(port, bit, mode)
Sets the specified port/bit to be an input
+pin. mode is a combination of one or more of
+the following. Note that some platforms may
+not support the desired mode. In that case,
+the value will not be defined so that the
+program will fail to compile.
  • 
+AO_EXTI_MODE_PULL_UP. Apply a pull-up to the
+pin; a disconnected pin will read as 1.
+
  • 
+AO_EXTI_MODE_PULL_DOWN. Apply a pull-down to
+the pin; a disconnected pin will read as 0.
+
  • 
+0. Don’t apply either a pull-up or
+pull-down. A disconnected pin will read an
+undetermined value.
+
2.2.2. Reading and writing GPIO pins
These macros read and write individual GPIO pins.
ao_gpio_set
#define ao_gpio_set(port, bit, pin, value)
Sets the specified port/bit or pin to
+the indicated value
ao_gpio_get
#define ao_gpio_get(port, bit, pin)
Returns either 1 or 0 depending on
+whether the input to the pin is high
+or low.
+== 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
+spaces. Furthermore, accessing stack variables is slow, and
+the 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.
When built on other architectures, the various SDCC-specific
+symbols are #defined as empty strings so they don’t affect the
+compiler.
2.3. 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
+space, and so it’s possible to convert any address into a
+unique 16-bit address. SDCC doesn’t know this, and so a
+global address to SDCC consumes 3 bytes of memory, 1 byte as
+a tag indicating the memory space and 2 bytes of offset within
+that space. AltOS avoids these 3-byte addresses as much as
+possible; using them involves a function call per byte
+access. The result is that nearly every variable declaration
+is decorated with a memory space identifier which clutters the
+code but makes the resulting code far smaller and more
+efficient.
2.3.1. __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
+confuse things further, the 8 general registers in the
+CPU are actually stored in this memory space. There are
+magic instructions to bank switch among 4 banks of
+these registers located at 0x00 - 0x1F. AltOS uses only
+the first bank at 0x00 - 0x07, leaving the other 24
+bytes available for other data.
2.3.2. __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.
2.3.3. __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.
2.3.4. __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.
2.3.5. __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.
2.3.6. __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.
2.3.7. sfr, sfr16, sfr32, sbit
Access to physical registers in the device use this mode
+which declares the variable name, its type and the
+address it lives at. No memory is allocated for these
+variables.
2.4. 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
+memory. Just like fortran. This makes these functions
+non-reentrant, and also consume space for parameters and
+locals even when they are not running. The benefit is smaller
+code and faster execution.
2.4.1. __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
+variables get allocated on the stack. This ensures that
+these values are not overwritten by another invocation of
+the function.
Functions which use significant amounts of space for
+arguments and/or local variables and which are not often
+invoked can also be marked as __reentrant. The resulting
+code will be larger, but the savings in memory are
+frequently worthwhile.
2.4.2. 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
+consuming data space for infrequently used variables in
+frequently used functions.
All library functions called by SDCC, including functions
+for multiplying and dividing large data types, are
+non-reentrant. Because of this, interrupt handlers must not
+invoke any library functions, including the multiply and
+divide code.
2.4.3. __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.
2.4.4. __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
+execution. Individual statements may also be marked as
+critical which blocks interrupts during the execution of
+that statement. Keeping critical sections as short as
+possible is key to ensuring that interrupts are handled as
+quickly as possible. AltOS doesn’t use this form in shared
+code as other compilers wouldn’t know what to do. Use
+ao_arch_block_interrupts and ao_arch_release_interrupts instead.
Chapter 3. Task functions
This chapter documents how to create, destroy and schedule
+AltOS tasks.
3.1. ao_add_task
void
+ao_add_task(__xdata struct ao_task * task,
+            void (*start)(void),
+            __code char *name);
This initializes the statically allocated task structure,
+assigns a name to it (not used for anything but the task
+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.
3.2. ao_exit
void
+ao_exit(void)
This terminates the current task.
3.3. ao_sleep
void
+ao_sleep(__xdata void *wchan)
This suspends the current task until wchan is signaled
+by ao_wakeup, or until the timeout, set by ao_alarm,
+fires. If wchan is signaled, ao_sleep returns 0, otherwise
+it returns 1. This is the only way to switch to another task.
Because ao_wakeup wakes every task waiting on a particular
+location, ao_sleep should be used in a loop that first checks
+the desired condition, blocks in ao_sleep and then rechecks
+until the condition is satisfied. If the location may be
+signaled from an interrupt handler, the code will need to
+block interrupts around the block of code. Here’s a complete
+example:
ao_arch_block_interrupts();
+while (!ao_radio_done)
+        ao_sleep(&ao_radio_done);
+ao_arch_release_interrupts();
3.4. ao_wakeup
void
+ao_wakeup(__xdata void *wchan)
Wake all tasks blocked on wchan. This makes them
+available to be run again, but does not actually switch
+to another task. Here’s an example of using this:
if (RFIF & RFIF_IM_DONE) {
+        ao_radio_done = 1;
+        ao_wakeup(&ao_radio_done);
+        RFIF &= ~RFIF_IM_DONE;
+}
Note that this need not block interrupts as the
+ao_sleep block can only be run from normal mode, and
+so this sequence can never be interrupted with
+execution of the other sequence.
3.5. ao_alarm
void
+ao_alarm(uint16_t delay);
 
-	  void
-	  ao_dma_alloc(uint8_t index);
-	

-	  Reserve a DMA engine for exclusive use by one
-	  driver.
-	
2.2. ao_dma_set_transfer
-	  void
-	  ao_dma_set_transfer(uint8_t id,
-	  void *peripheral,
-	  void *memory,
-	  uint16_t count,
-	  uint32_t ccr);
-	

-	  Initializes the specified dma engine to copy data between
-	  'peripheral' and 'memory' for 'count' units. 'ccr' is a
-	  value directly out of the STM32L documentation and tells the
-	  DMA engine what the transfer unit size, direction and step
-	  are.
-	
2.3. ao_dma_set_isr
-	  void
-	  ao_dma_set_isr(uint8_t index, void (*isr)(int))
-	

-	  This sets a function to be called when the DMA transfer
-	  completes in lieu of setting the ao_dma_done bits. Use this
-	  when some work needs to be done when the DMA finishes that
-	  cannot wait until user space resumes.
-	
2.4. 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_done[index]' is cleared when the DMA is started, and
-	  then receives the AO_DMA_DONE bit on a successful transfer
-	  or the 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.
-	
2.5. ao_dma_done_transfer
-	  void
-	  ao_dma_done_transfer(uint8_t id);
-	

-	  Signals that a specific DMA engine is done being used. This
-	  allows multiple drivers to use the same DMA engine safely.
-	
2.6. ao_dma_abort
-	  void
-	  ao_dma_abort(uint8_t id)
-	

-	  Terminate any in-progress DMA transaction, marking its
-	  'done' variable with the AO_DMA_ABORTED bit.
-	
Chapter 8. Stdio interface
Table of Contents
1. putchar
2. getchar
3. flush
4. ao_add_stdio

-      AltOS offers a stdio interface over USB, serial and the RF
-      packet link. This provides for control of the device locally or
-      remotely. This is hooked up to the stdio functions by providing
-      the standard putchar/getchar/flush functions. These
-      automatically multiplex the available communication channels;
-      output is always delivered to the channel which provided the
-      most recent input.
-    
1. putchar
-	void
-	putchar(char c)
-      

-	Delivers a single character to the current console
-	device.
-      
2. getchar
-	char
-	getchar(void)
-      

-	Reads a single character from any of the available
-	console devices. The current console device is set to
-	that which delivered this character. This blocks until
-	a character is available.
-      
3. flush
-	void
-	flush(void)
-      

-	Flushes the current console device output buffer. Any
-	pending characters will be delivered to the target device.
-      
4. ao_add_stdio
-	void
-	ao_add_stdio(char (*pollchar)(void),
-	                   void (*putchar)(char),
-	                   void (*flush)(void))
-      

-	This adds another console device to the available
-	list.
-      

-	'pollchar' returns either an available character or
-	AO_READ_AGAIN if none is available. Significantly, it does
-	not block. The device driver must set 'ao_stdin_ready' to
-	1 and call ao_wakeup(&ao_stdin_ready) when it receives
-	input to tell getchar that more data is available, at
-	which point 'pollchar' will be called again.
-      

-	'putchar' queues a character for output, flushing if the output buffer is
-	full. It may block in this case.
-      

-	'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 9. Command line interface
Table of Contents
1. ao_cmd_register
2. ao_cmd_lex
3. ao_cmd_put16
4. ao_cmd_put8
5. ao_cmd_white
6. ao_cmd_hex
7. ao_cmd_decimal
8. ao_match_word
9. ao_cmd_init

-      AltOS includes a simple command line parser which is hooked up
-      to the stdio interfaces permitting remote control of the device
-      over USB, serial 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.
-    
1. ao_cmd_register
-	void
-	ao_cmd_register(__code struct ao_cmds *cmds)
-      

-	This registers a set of commands with the command
-	parser. There is a fixed limit on the number of command
-	sets, the system will panic if too many are registered.
-	Each command is defined by a struct ao_cmds entry:
-	
-	  struct ao_cmds {
-	          char		cmd;
-	          void		(*func)(void);
-	          const char	*help;
-	  };
-	

-	'cmd' is the character naming the command. 'func' is the
-	function to invoke and 'help' is a string displayed by the
-	'?' command. Syntax errors found while executing 'func'
-	should be indicated by modifying the global ao_cmd_status
-	variable with one of the following values:
-	
ao_cmd_success

-		The command was parsed successfully. There is no
-		need to assign this value, it is the default.
-	      
ao_cmd_lex_error

-		A token in the line was invalid, such as a number
-		containing invalid characters. The low-level
-		lexing functions already assign this value as needed.
-	      
ao_syntax_error

-		The command line is invalid for some reason other
-		than invalid tokens.
-	      

-      
2. 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.
-      
3. ao_cmd_put16
-	void
-	ao_cmd_put16(uint16_t v);
-      

-	Writes 'v' as four hexadecimal characters.
-      
4. ao_cmd_put8
-	void
-	ao_cmd_put8(uint8_t v);
-      

-	Writes 'v' as two hexadecimal characters.
-      
5. 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.
-      
6. 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;
-      
7. ao_cmd_decimal
-	void
-	ao_cmd_decimal(void)
-      

-	This reads a 32-bit decimal value from the command
-	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;
-      
8. ao_match_word
-	uint8_t
-	ao_match_word(__code char *word)
-      

-	This checks to make sure that 'word' occurs on the command
-	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.
-      
9. 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 10. USB target device
Table of Contents
1. ao_usb_flush
2. ao_usb_putchar
3. ao_usb_pollchar
4. ao_usb_getchar
5. ao_usb_disable
6. ao_usb_enable
7. ao_usb_init

-      AltOS contains a full-speed USB target device driver. It can be
-      programmed to offer any kind of USB target, but to simplify
-      interactions with a variety of operating systems, AltOS provides
-      only a single target device profile, that of a USB modem which
-      has native drivers for Linux, Windows and Mac OS X. It would be
-      easy to change the code to provide an alternate target device if
-      necessary.
-    

-      To the rest of the system, the USB device looks like a simple
-      two-way byte stream. It can be hooked into the command line
-      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.
-    
1. ao_usb_flush
-	void
-	ao_usb_flush(void);
-      

-	Flushes any pending USB output. This queues an 'IN' packet
-	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.
-      
2. ao_usb_putchar
-	void
-	ao_usb_putchar(char c);
-      

-	If there is a pending 'IN' packet awaiting delivery to the
-	host, this blocks until that has been fetched. Then, this
-	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.
-      
3. ao_usb_pollchar
-	char
-	ao_usb_pollchar(void);
-      

-	If there are no characters remaining in the last 'OUT'
-	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.
-      
4. 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.
-      
5. ao_usb_disable
-	void
-	ao_usb_disable(void);
-      

-	This turns off the USB controller. It will no longer
-	respond to host requests, nor return characters. Calling
-	any of the i/o routines while the USB device is disabled
-	is undefined, and likely to break things. Disabling the
-	USB device when not needed saves power.
-      

-	Note that neither TeleDongle nor TeleMetrum are able to
-	signal to the USB host that they have disconnected, so
-	after disabling the USB device, it's likely that the cable
-	will need to be disconnected and reconnected before it
-	will work again.
-      
6. ao_usb_enable
-	void
-	ao_usb_enable(void);
-      

-	This turns the USB controller on again after it has been
-	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.
-      
7. ao_usb_init
-	void
-	ao_usb_init(void);
-      

-	This turns the USB controller on, adds a task to handle
-	the control end point and adds the usb I/O functions to
-	the stdio system. Call this from main before
-	ao_start_scheduler.
-      
Chapter 11. Serial peripherals
Table of Contents
1. ao_serial_getchar
2. ao_serial_putchar
3. ao_serial_drain
4. ao_serial_set_speed
5. ao_serial_init

-      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
-      in 8-bits, no parity, 1 stop bit framing. The default
-      configuration has clock settings for 4800, 9600 and 57600 baud
-      operation. Additional speeds can be added by computing
-      appropriate clock values.
-    

-      To prevent loss of data, AltOS provides receive and transmit
-      fifos of 32 characters each.
-    
1. 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.
-      
2. 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.
-      
3. ao_serial_drain
-	void
-	ao_serial_drain(void);
-      

-	Blocks until the transmit fifo is empty. Used internally
-	when changing serial speeds.
-      
4. ao_serial_set_speed
-	void
-	ao_serial_set_speed(uint8_t speed);
-      

-	Changes the serial baud rate to one of
-	AO_SERIAL_SPEED_4800, AO_SERIAL_SPEED_9600 or
-	AO_SERIAL_SPEED_57600. This first flushes the transmit
-	fifo using ao_serial_drain.
-      
5. 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 12. CC1111 Radio peripheral
Table of Contents
1. Radio Introduction
2. ao_radio_set_telemetry
3. ao_radio_set_packet
4. ao_radio_set_rdf
5. ao_radio_idle
6. ao_radio_get
7. ao_radio_put
8. ao_radio_abort
9. Radio Telemetry
9.1. ao_radio_send
9.2. ao_radio_recv
10. Radio Direction Finding
10.1. ao_radio_rdf
11. Radio Packet Mode
11.1. ao_packet_putchar
11.2. ao_packet_pollchar
11.3. ao_packet_slave_start
11.4. ao_packet_slave_stop
11.5. ao_packet_slave_init
11.6. ao_packet_master_init
1. Radio Introduction

-	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
-	devices, using it for other tasks may require customization of
-	the driver itself. There are three basic modes of operation:
-	
  1. 
-	      Telemetry mode. In this mode, TeleMetrum transmits telemetry
-	      frames at a fixed rate. The frames are of fixed size. This
-	      is strictly a one-way communication from TeleMetrum to
-	      TeleDongle.
-	    
  2. 
-	      Packet mode. In this mode, the radio is used to create a
-	      reliable duplex byte stream between TeleDongle and
-	      TeleMetrum. This is an asymmetrical protocol with
-	      TeleMetrum only transmitting in response to a packet sent
-	      from TeleDongle. Thus getting data from TeleMetrum to
-	      TeleDongle requires polling. The polling rate is adaptive,
-	      when no data has been received for a while, the rate slows
-	      down. The packets are checked at both ends and invalid
-	      data are ignored.
-	    
    
-	      On the TeleMetrum side, the packet link is hooked into the
-	      stdio mechanism, providing an alternate data path for the
-	      command processor. It is enabled when the unit boots up in
-	      'idle' mode.
-	    
    
-	      On the TeleDongle side, the packet link is enabled with a
-	      command; data from the stdio package is forwarded over the
-	      packet link providing a connection from the USB command
-	      stream to the remote TeleMetrum device.
-	    
  3. 
-	      Radio Direction Finding mode. In this mode, TeleMetrum
-	      constructs a special packet that sounds like an audio tone
-	      when received by a conventional narrow-band FM
-	      receiver. This is designed to provide a beacon to track
-	      the device when other location mechanisms fail.
-	    

-      
2. ao_radio_set_telemetry
-	  void
-	  ao_radio_set_telemetry(void);
-	

-	  Configures the radio to send or receive telemetry
-	  packets. This includes packet length, modulation scheme and
-	  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.
-	
3. ao_radio_set_packet
-	  void
-	  ao_radio_set_packet(void);
-	

-	  Configures the radio to send or receive packet data.  This
-	  includes packet length, modulation scheme and 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.
-	
4. ao_radio_set_rdf
-	  void
-	  ao_radio_set_rdf(void);
-	

-	  Configures the radio to send RDF 'packets'. An RDF 'packet'
-	  is a sequence of hex 0x55 bytes sent at a base bit rate of
-	  2kbps using a 5kHz deviation. All of the error correction
-	  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.
-	
5. 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.
-	
6. 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.
-	
7. ao_radio_put
-	  void
-	  ao_radio_put(void);
-	

-	  Releases the radio mutex.
-	
8. ao_radio_abort
-	  void
-	  ao_radio_abort(void);
-	

-	  Aborts any transmission or reception process by aborting the
-	  associated DMA object and calling ao_radio_idle to terminate
-	  the radio operation.
-	
9. Radio Telemetry

-	In telemetry mode, you can send or receive a telemetry
-	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.
-      
9.1. ao_radio_send
-	  void
-	  ao_radio_send(__xdata struct ao_telemetry *telemetry);
-	

-	  This sends the specific telemetry packet, waiting for the
-	  transmission to complete. The radio must have been set to
-	  telemetry mode. This function calls ao_radio_get() before
-	  sending, and ao_radio_put() afterwards, to correctly
-	  serialize access to the radio device.
-	
9.2. ao_radio_recv
-	  void
-	  ao_radio_recv(__xdata struct ao_radio_recv *radio);
-	

-	  This blocks waiting for a telemetry packet to be received.
-	  The radio must have been set to telemetry mode. This
-	  function calls ao_radio_get() before receiving, and
-	  ao_radio_put() afterwards, to correctly serialize access
-	  to the radio device. This returns non-zero if a packet was
-	  received, or zero if the operation was aborted (from some
-	  other task calling ao_radio_abort()).
-	
10. Radio Direction Finding

-	In radio direction finding mode, there's just one function to
-	use
-      
10.1. ao_radio_rdf
-	  void
-	  ao_radio_rdf(int ms);
-	

-	  This sends an RDF packet lasting for the specified amount
-	  of time. The maximum length is 1020 ms.
-	
11. Radio Packet Mode

-	Packet mode is asymmetrical and is configured at compile time
-	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.
-      
11.1. ao_packet_putchar
-	  void
-	  ao_packet_putchar(char c);
-	

-	  If the output queue is full, this first blocks waiting for
-	  that data to be delivered. Then, queues a character for
-	  packet transmission. On the master side, this will
-	  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.
-	
11.2. 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.
-	
11.3. 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.
-	
11.4. ao_packet_slave_stop
-	  void
-	  ao_packet_slave_stop(void);
-	

-	  Disables the packet slave task, stopping the radio receiver.
-	
11.5. 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.
-	
11.6. ao_packet_master_init
-	  void
-	  ao_packet_master_init(void);
-	

-	  Adds the 'p' packet forward command to start packet mode.
-	

+void
+ao_clear_alarm(void);

Schedules an alarm to fire in at least delay +ticks. If the task is asleep when the alarm fires, it +will wakeup and ao_sleep will return 1. ao_clear_alarm +resets any pending alarm so that it doesn’t fire at +some arbitrary point in the future.

ao_alarm(ao_packet_master_delay);
+ao_arch_block_interrupts();
+while (!ao_radio_dma_done)
+if (ao_sleep(&ao_radio_dma_done) != 0)
+ao_radio_abort();
+ao_arch_release_interrupts();
+ao_clear_alarm();

In this example, a timeout is set before waiting for +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.

3.6. 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.

3.7. ao_clock_init

void
+ao_clock_init(void);

This initializes the main CPU clock and switches to it.

Chapter 4. Timer Functions

AltOS sets up one of the CPU 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 +waiting for that time to pass, then fires off the sensors to +collect current data readings. Doing this from the ISR ensures +that the values are sampled at a regular rate, independent +of any scheduling jitter.

4.1. 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.

4.2. ao_delay

void
+ao_delay(uint16_t ticks);

Suspend the current task for at least ticks clock units.

4.3. 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.

4.4. ao_timer_init

void
+ao_timer_init(void)

This turns on the 100Hz tick. 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

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.

5.1. ao_mutex_get

void
+ao_mutex_get(__xdata uint8_t *mutex);

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

5.2. ao_mutex_put

void
+ao_mutex_put(__xdata uint8_t *mutex);

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

Chapter 6. DMA engine

The CC1111 and STM32L both contain a useful bit of extra +hardware in the form of a number of programmable DMA +engines. They can be configured to copy data in memory, or +between memory and devices (or even between two devices). AltOS +exposes a general interface to this hardware and uses it to +handle both internal and external devices.

Because the CC1111 and STM32L DMA engines are different, the +interface to them is also different. As the DMA engines are +currently used to implement platform-specific drivers, this +isn’t yet a problem.

Code using a DMA engine should allocate one at startup +time. There is no provision to free them, and if you run out, +AltOS will simply panic.

During operation, the DMA engine is initialized with the +transfer parameters. Then it is started, at which point it +awaits a suitable event to start copying data. When copying data +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.

6.1. CC1111 DMA Engine

6.1.1. ao_dma_alloc

uint8_t
+ao_dma_alloc(__xdata uint8_t *done)

Allocate a DMA engine, returning the +identifier. done is cleared when the DMA is +started, and then receives the AO_DMA_DONE bit +on a successful transfer or the 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.

6.1.2. ao_dma_set_transfer

void
+ao_dma_set_transfer(uint8_t id,
+void __xdata *srcaddr,
+void __xdata *dstaddr,
+uint16_t count,
+uint8_t cfg0,
+uint8_t cfg1)

Initializes the specified dma engine to copy +data from srcaddr to dstaddr for count +units. cfg0 and cfg1 are values directly out +of the CC1111 documentation and tell the DMA +engine what the transfer unit size, direction +and step are.

6.1.3. 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.

6.1.4. ao_dma_trigger

void
+ao_dma_trigger(uint8_t id)

Trigger the specified DMA engine to start +copying data.

6.1.5. ao_dma_abort

void
+ao_dma_abort(uint8_t id)

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

6.2. STM32L DMA Engine

6.2.1. ao_dma_alloc

uint8_t ao_dma_done[];
+
+void
+ao_dma_alloc(uint8_t index);

Reserve a DMA engine for exclusive use by one +driver.

6.2.2. ao_dma_set_transfer

void
+ao_dma_set_transfer(uint8_t id,
+void *peripheral,
+void *memory,
+uint16_t count,
+uint32_t ccr);

Initializes the specified dma engine to copy +data between peripheral and memory for +count units. ccr is a value directly out +of the STM32L documentation and tells the DMA +engine what the transfer unit size, direction +and step are.

6.2.3. ao_dma_set_isr

void
+ao_dma_set_isr(uint8_t index, void (*isr)(int))

This sets a function to be called when the DMA +transfer completes in lieu of setting the +ao_dma_done bits. Use this when some work +needs to be done when the DMA finishes that +cannot wait until user space resumes.

6.2.4. 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_done[index] +is cleared when the DMA is started, and then +receives the AO_DMA_DONE bit on a successful +transfer or the 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.

6.2.5. ao_dma_done_transfer

void
+ao_dma_done_transfer(uint8_t id);

Signals that a specific DMA engine is done +being used. This allows multiple drivers to +use the same DMA engine safely.

6.2.6. ao_dma_abort

void
+ao_dma_abort(uint8_t id)

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

Chapter 7. Stdio interface

AltOS offers a stdio interface over USB, serial and the RF +packet link. This provides for control of the device locally or +remotely. This is hooked up to the stdio functions by providing +the standard putchar/getchar/flush functions. These +automatically multiplex the available communication channels; +output is always delivered to the channel which provided the +most recent input.

7.1. putchar

void
+putchar(char c)

Delivers a single character to the current console +device.

7.2. getchar

char
+getchar(void)

Reads a single character from any of the available +console devices. The current console device is set to +that which delivered this character. This blocks until +a character is available.

7.3. flush

void
+flush(void)

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

7.4. ao_add_stdio

void
+ao_add_stdio(char (*pollchar)(void),
+void (*putchar)(char),
+void (*flush)(void))

This adds another console device to the available +list.

pollchar returns either an available character or +AO_READ_AGAIN if none is available. Significantly, it does +not block. The device driver must set ao_stdin_ready to +1 and call ao_wakeup(&ao_stdin_ready) when it receives +input to tell getchar that more data is available, at +which point pollchar will be called again.

putchar queues a character for output, flushing if the output buffer is +full. It may block in this case.

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, serial 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.

8.1. ao_cmd_register

void
+ao_cmd_register(__code struct ao_cmds *cmds)

This registers a set of commands with the command +parser. There is a fixed limit on the number of command +sets, the system will panic if too many are registered. +Each command is defined by a struct ao_cmds entry:

struct ao_cmds {
+        char            cmd;
+        void            (*func)(void);
+        const char      *help;
+};

cmd is the character naming the command. func is the +function to invoke and help is a string displayed by the +? command. Syntax errors found while executing func +should be indicated by modifying the global ao_cmd_status +variable with one of the following values:

+ao_cmd_success +
+The command was parsed successfully. There is no need +to assign this value, it is the default. +
+ao_cmd_lex_error +
+A token in the line was invalid, such as a number +containing invalid characters. The low-level lexing +functions already assign this value as needed. +
+ao_syntax_error +
+The command line is invalid for some reason other than +invalid tokens. +

8.2. 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.

8.3. ao_cmd_put16

void
+ao_cmd_put16(uint16_t v);

Writes v as four hexadecimal characters.

8.4. ao_cmd_put8

void
+ao_cmd_put8(uint8_t v);

Writes v as two hexadecimal characters.

8.5. 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.

8.6. 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;

8.7. ao_cmd_decimal

void
+ao_cmd_decimal(void)

This reads a 32-bit decimal value from the command +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;

8.8. ao_match_word

uint8_t
+ao_match_word(__code char *word)

This checks to make sure that word occurs on the +command 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.

8.9. 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. USB target device

AltOS contains a full-speed USB target device driver. It can +be programmed to offer any kind of USB target, but to simplify +interactions with a variety of operating systems, AltOS +provides only a single target device profile, that of a USB +modem which has native drivers for Linux, Windows and Mac OS +X. It would be easy to change the code to provide an alternate +target device if necessary.

To the rest of the system, the USB device looks like a simple +two-way byte stream. It can be hooked into the command line +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.

9.1. ao_usb_flush

void
+ao_usb_flush(void);

Flushes any pending USB output. This queues an IN +packet 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.

9.2. ao_usb_putchar

void
+ao_usb_putchar(char c);

If there is a pending IN packet awaiting delivery to +the host, this blocks until that has been +fetched. Then, this 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.

9.3. ao_usb_pollchar

char
+ao_usb_pollchar(void);

If there are no characters remaining in the last OUT +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.

9.4. 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.

9.5. ao_usb_disable

void
+ao_usb_disable(void);

This turns off the USB controller. It will no longer +respond to host requests, nor return +characters. Calling any of the i/o routines while the +USB device is disabled is undefined, and likely to +break things. Disabling the USB device when not needed +saves power.

Note that neither TeleDongle v0.2 nor TeleMetrum v1 +are able to signal to the USB host that they have +disconnected, so after disabling the USB device, it’s +likely that the cable will need to be disconnected and +reconnected before it will work again.

9.6. ao_usb_enable

void
+ao_usb_enable(void);

This turns the USB controller on again after it has +been 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.

9.7. ao_usb_init

void
+ao_usb_init(void);

This turns the USB controller on, adds a task to +handle 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. Serial peripherals

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 in 8-bits, no parity, 1 stop bit framing. The default +configuration has clock settings for 4800, 9600 and 57600 baud +operation. Additional speeds can be added by computing +appropriate clock values.

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

10.1. 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.

10.2. 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.

10.3. ao_serial_drain

void
+ao_serial_drain(void);

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

10.4. ao_serial_set_speed

void
+ao_serial_set_speed(uint8_t speed);

Changes the serial baud rate to one of +AO_SERIAL_SPEED_4800, AO_SERIAL_SPEED_9600 or +AO_SERIAL_SPEED_57600. This first flushes the transmit +fifo using ao_serial_drain.

10.5. 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/CC1120/CC1200 Radio peripheral

11.1. Radio Introduction

The CC1111, CC1120 and CC1200 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 +devices, using it for other tasks may require +customization of the driver itself. There are three +basic modes of operation:

  1. +Telemetry mode. In this mode, TeleMetrum transmits telemetry +frames at a fixed rate. The frames are of fixed size. This +is strictly a one-way communication from TeleMetrum to +TeleDongle. +
  2. +Packet mode. In this mode, the radio is used to create a +reliable duplex byte stream between TeleDongle and +TeleMetrum. This is an asymmetrical protocol with +TeleMetrum only transmitting in response to a packet sent +from TeleDongle. Thus getting data from TeleMetrum to +TeleDongle requires polling. The polling rate is adaptive, +when no data has been received for a while, the rate slows +down. The packets are checked at both ends and invalid data +are ignored. +

On the TeleMetrum side, the packet link is hooked into the +stdio mechanism, providing an alternate data path for the +command processor. It is enabled when the unit boots up in +idle mode.

On the TeleDongle side, the packet link is enabled with a +command; data from the stdio package is forwarded over the +packet link providing a connection from the USB command +stream to the remote TeleMetrum device.

  1. +Radio Direction Finding mode. In this mode, TeleMetrum +constructs a special packet that sounds like an audio tone +when received by a conventional narrow-band FM +receiver. This is designed to provide a beacon to track the +device when other location mechanisms fail. +

11.2. ao_radio_set_telemetry

void
+ao_radio_set_telemetry(void);

Configures the radio to send or receive telemetry +packets. This includes packet length, modulation scheme and +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.

11.3. ao_radio_set_packet

void
+ao_radio_set_packet(void);

Configures the radio to send or receive packet data. This +includes packet length, modulation scheme and 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.

11.4. ao_radio_set_rdf

void
+ao_radio_set_rdf(void);

Configures the radio to send RDF packets. An RDF packet +is a sequence of hex 0x55 bytes sent at a base bit rate of +2kbps using a 5kHz deviation. All of the error correction +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.

11.5. 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.

11.6. 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.

11.7. ao_radio_put

void
+ao_radio_put(void);

Releases the radio mutex.

11.8. ao_radio_abort

void
+ao_radio_abort(void);

Aborts any transmission or reception process by aborting the +associated DMA object and calling ao_radio_idle to terminate +the radio operation.

11.9. Radio Telemetry

In telemetry mode, you can send or receive a telemetry +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.

11.9.1. ao_radio_send

void
+ao_radio_send(__xdata struct ao_telemetry *telemetry);

This sends the specific telemetry packet, waiting for the +transmission to complete. The radio must have been set to +telemetry mode. This function calls ao_radio_get() before +sending, and ao_radio_put() afterwards, to correctly +serialize access to the radio device.

11.9.2. ao_radio_recv

void
+ao_radio_recv(__xdata struct ao_radio_recv *radio);

This blocks waiting for a telemetry packet to be received. +The radio must have been set to telemetry mode. This +function calls ao_radio_get() before receiving, and +ao_radio_put() afterwards, to correctly serialize access +to the radio device. This returns non-zero if a packet was +received, or zero if the operation was aborted (from some +other task calling ao_radio_abort()).

11.10. Radio Direction Finding

In radio direction finding mode, there’s just one function to +use

11.10.1. ao_radio_rdf

void
+ao_radio_rdf(int ms);

This sends an RDF packet lasting for the specified amount +of time. The maximum length is 1020 ms.

11.11. Radio Packet Mode

Packet mode is asymmetrical and is configured at compile time +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.

11.11.1. ao_packet_putchar

void
+ao_packet_putchar(char c);

If the output queue is full, this first blocks waiting for +that data to be delivered. Then, queues a character for +packet transmission. On the master side, this will +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.

11.11.2. 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.

11.11.3. 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.

11.11.4. ao_packet_slave_stop

void
+ao_packet_slave_stop(void);

Disables the packet slave task, stopping the radio receiver.

11.11.5. 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.

11.11.6. ao_packet_master_init

void
+ao_packet_master_init(void);

Adds the p packet forward command to start packet mode.

\ No newline at end of file diff --git a/AltOS/doc/altos.pdf b/AltOS/doc/altos.pdf index a6bf901..36eca07 100644 Binary files a/AltOS/doc/altos.pdf and b/AltOS/doc/altos.pdf differ diff --git a/AltOS/doc/altusmetrum-revhistory.html b/AltOS/doc/altusmetrum-revhistory.html index becc94b..48b7963 100644 --- a/AltOS/doc/altusmetrum-revhistory.html +++ b/AltOS/doc/altusmetrum-revhistory.html @@ -1,5 +1,7 @@ -Revision History
Revision History
Revision 1.8.311 Dec 2017
+Revision History
Revision History
Revision 1.8.420 Dec 2017
+ Support EasyMini v2.0 hardware. +
Revision 1.8.311 Dec 2017
Support TeleMega v3.0 hardware. Fix one firmware bug affecting all flight computers and another two affecting TeleMega and EasyMega. Several new AltosUI graphing features. diff --git a/AltOS/doc/altusmetrum.html b/AltOS/doc/altusmetrum.html index ee93354..69e25f8 100644 --- a/AltOS/doc/altusmetrum.html +++ b/AltOS/doc/altusmetrum.html @@ -19,7 +19,7 @@ collaborators, and we certainly appreciate this level of contribution!

Have fun using these products, and we hope to meet all of you out on the rocket flight line somewhere.

Bdale Garbee, KB0G
NAR #87103, TRA #12201

Keith Packard, KD7SQG
-NAR #88757, TRA #12200

Table of Contents

1. Introduction and Overview
2. Getting Started
2.1. Batteries
2.2. Ground Station Hardware
2.3. Linux/Mac/Windows Ground Station Software
2.4. Android Ground Station Software
3. Using Altus Metrum Hardware
3.1. Wiring and Electrical Interference
3.2. Hooking Up Lithium Polymer Batteries
3.3. Hooking Up Pyro Charges
3.4. Hooking Up a Power Switch
3.5. Understanding Beeps
3.6. Turning On the Power
3.7. Using an External Active Switch Circuit
3.8. Using a Separate Pyro Battery
3.9. Using a Different Kind of Battery
4. TeleMetrum
4.1. TeleMetrum Screw Terminals
4.2. Using a Separate Pyro Battery with TeleMetrum
4.3. Using an Active Switch with TeleMetrum
5. TeleMini
5.1. TeleMini v3 Screw Terminals
5.2. Using a Separate Pyro Battery with TeleMini v3
5.3. Using an Active Switch with TeleMini v3
5.4. TeleMini v1
6. EasyMini
6.1. EasyMini Screw Terminals
6.2. Connecting A Battery To EasyMini
6.3. Charging Lithium Batteries
6.4. Using a Separate Pyro Battery with EasyMini
6.5. Using an Active Switch with EasyMini
7. TeleMega
7.1. TeleMega Screw Terminals
7.2. Using a Separate Pyro Battery with TeleMega
7.3. Using Only One Battery With TeleMega
7.4. Using an Active Switch with TeleMega
8. EasyMega
8.1. EasyMega Screw Terminals
8.2. Using a Separate Pyro Battery with EasyMega
8.3. Using Only One Battery With EasyMega
8.4. Using an Active Switch with EasyMega
9. Installation
10. Using Altus Metrum Products
10.1. Being Legal
10.2. In the Rocket
10.3. On the Ground
10.4. Data Analysis
10.5. Future Plans
11. AltosUI
11.1. Monitor Flight
11.1.1. Launch Pad
11.1.2. Ascent
11.1.3. Descent
11.1.4. Landed
11.1.5. Table
11.1.6. Site Map
11.1.7. Igniter
11.2. Save Flight Data
11.3. Replay Flight
11.4. Graph Data
11.4.1. Flight Graph
11.4.2. Configure Graph
11.4.3. Flight Statistics
11.4.4. Map
11.5. Export Data
11.5.1. Comma Separated Value Format
11.5.2. Keyhole Markup Language (for Google Earth)
11.6. Configure Altimeter
11.6.1. Main Deploy Altitude
11.6.2. Apogee Delay
11.6.3. Apogee Lockout
11.6.4. Frequency
11.6.5. RF Calibration
11.6.6. Telemetry/RDF/APRS Enable
11.6.7. Telemetry baud rate
11.6.8. APRS Interval
11.6.9. APRS SSID
11.6.10. APRS Format
11.6.11. Callsign
11.6.12. Maximum Flight Log Size
11.6.13. Ignitor Firing Mode
11.6.14. Pad Orientation
11.6.15. Beeper Frequency
11.6.16. Logging Trigger Motion
11.6.17. Position Reporting Interval
11.6.18. Calibrate Accelerometer
11.6.19. Configure Pyro Channels
11.7. Configure AltosUI
11.7.1. Voice Settings
11.7.2. Log Directory
11.7.3. Callsign
11.7.4. Imperial Units
11.7.5. Serial Debug
11.7.6. Font size
11.7.7. Look & feel
11.7.8. Menu position
11.7.9. Map Cache Size
11.7.10. Manage Frequencies
11.8. Configure Groundstation
11.8.1. Frequency
11.8.2. RF Calibration
11.8.3. Telemetry Rate
11.9. Flash Image
11.10. Fire Igniter
11.11. Scan Channels
11.12. Load Maps
11.13. Monitor Idle
12. AltosDroid
12.1. Installing AltosDroid
12.2. Charging TeleBT Battery
12.3. Connecting to TeleBT over Bluetooth™
12.4. Connecting to TeleDongle or TeleBT over USB
12.5. AltosDroid Menu
12.6. Setup
12.7. Idle Mode
12.8. AltosDroid Flight Monitoring
12.9. Pad
12.10. Flight
12.11. Recover
12.12. Map
12.13. Downloading Flight Logs
A. System Operation
A.1. Firmware Modes
A.2. GPS
A.3. Controlling An Altimeter Over The Radio Link
A.4. Ground Testing
A.5. Radio Link
A.6. APRS
A.7. Configurable Parameters
B. Handling Precautions
C. Updating Device Firmware
C.1. Updating TeleMega, TeleMetrum v2, EasyMega, EasyMini or TeleDongle v3 Firmware
C.1.1. Recovering From Self-Flashing Failure
C.2. Pair Programming
C.2.1. Updating TeleMetrum v1.x Firmware
C.2.2. Updating TeleMini v1.0 Firmware
C.2.3. Updating TeleDongle v0.2 Firmware
D. Flight Data Recording
E. Altus Metrum Hardware Specifications
F. Release Notes
F.1. Release Notes for Version 1.8.3
F.1.1. AltOS
F.1.2. AltosUI and TeleGPS Applications
F.2. Release Notes for Version 1.8.2
F.2.1. AltOS
F.2.2. AltosUI and TeleGPS Applications
F.3. Release Notes for Version 1.8.1
F.3.1. AltOS
F.3.2. AltosUI and TeleGPS Applications
F.4. Release Notes for Version 1.8
F.4.1. AltOS
F.4.2. AltosUI and TeleGPS Applications
F.5. Release Notes for Version 1.7
F.5.1. AltOS
F.5.2. AltosUI and TeleGPS Applications
F.6. Release Notes for Version 1.6.8
F.6.1. AltOS
F.6.2. AltosUI, TeleGPS and AltosDroid Applications
F.7. Release Notes for Version 1.6.5
F.7.1. AltOS
F.7.2. AltosUI, TeleGPS and AltosDroid Applications
F.8. Release Notes for Version 1.6.4
F.8.1. AltOS
F.8.2. AltosUI, TeleGPS and AltosDroid Applications
F.8.3. Documentation
F.9. Release Notes for Version 1.6.3
F.9.1. AltOS
F.9.2. AltosUI and TeleGPS Applications
F.9.3. AltosDroid
F.9.4. Documentation
F.10. Release Notes for Version 1.6.2
F.10.1. AltOS
F.10.2. AltosUI and TeleGPS Applications
F.10.3. Documentation
F.11. Release Notes for Version 1.6.1
F.11.1. AltOS
F.11.2. AltosUI and TeleGPS Applications
F.11.3. AltosDroid
F.12. Release Notes for Version 1.6
F.12.1. AltOS
F.12.2. AltosUI and TeleGPS Applications
F.13. Release Notes for Version 1.5
F.13.1. AltOS
F.13.2. AltosUI and TeleGPS Applications
F.14. Release Notes for Version 1.4.2
F.14.1. AltosUI and TeleGPS Applications
F.15. Release Notes for Version 1.4.1
F.15.1. AltosUI and TeleGPS Applications:
F.16. Release Notes for Version 1.4
F.16.1. AltOS
F.16.2. AltosUI Application
F.16.3. TeleGPS Application
F.16.4. Documentation
F.17. Release Notes for Version 1.3.2
F.17.1. AltOS
F.17.2. AltosUI Application
F.18. Release Notes for Version 1.3.1
F.18.1. AltOS
F.18.2. AltosUI Application
F.19. Release Notes for Version 1.3
F.19.1. AltOS
F.19.2. AltosUI Application
F.20. Release Notes for Version 1.2.1
F.20.1. AltOS
F.20.2. AltosUI Application
F.20.3. AltosDroid
F.21. Release Notes for Version 1.2
F.21.1. AltOS
F.21.2. AltosUI and MicroPeak Application
F.22. Release Notes for Version 1.1
F.22.1. AltOS
F.22.2. AltosUI
F.23. Release Notes for Version 1.1
F.23.1. AltOS
F.23.2. AltosUI
F.24. Release Notes for Version 1.0.1
F.24.1. AltOS
F.24.2. AltosUI Application
F.25. Release Notes for Version 0.9.2
F.25.1. AltosUI
F.26. Release Notes for Version 0.9
F.26.1. AltOS
F.26.2. AltosUI Application
F.27. Release Notes for Version 0.8
F.27.1. AltosUI Application:
F.28. Release Notes for Version 0.7.1
F.28.1. AltosUI Application

List of Figures

4.1. TeleMetrum v2 Board
4.2. TeleMetrum v1 Board
5.1. TeleMini v3 Board
5.2. TeleMini v1 Board
6.1. EasyMini Board
7.1. TeleMega Board
8.1. EasyMega Board
11.1. AltosUI Main Window
11.2. Device Selection Dialog
11.3. Monitor Flight Launch Pad View
11.4. Monitor Flight Ascent View
11.5. Monitor Flight Descent View
11.6. Monitor Flight Landed View
11.7. Monitor Flight Table View
11.8. Monitor Flight Site Map View
11.9. Monitor Flight Additional Igniter View
11.10. Flight Data Graph
11.11. Flight Graph Configuration
11.12. Flight Statistics
11.13. Flight Map
11.14. Altimeter Configuration
11.15. Additional Pyro Channel Configuration
11.16. Configure AltosUI Dialog
11.17. Configure Groundstation Dialog
11.18. Fire Igniter Window
11.19. Scan Channels Window
11.20. Load Maps Window
11.21. Monitor Idle Window

List of Tables

3.1. AltOS Modes
3.2. Pad/Idle Indications
3.3. Pad Radio Indications
4.1. TeleMetrum Screw Terminals
5.1. TeleMini v3 Screw Terminals
6.1. EasyMini Screw Terminals
7.1. TeleMega Screw Terminals
8.1. EasyMega Screw Terminals
A.1. Altus Metrum APRS Comments
D.1. Data Storage on Altus Metrum altimeters
E.1. Altus Metrum Flight Computer Electronics
E.2. Altus Metrum Flight Computer Mechanical Components

Chapter 1. Introduction and Overview

Welcome to the Altus Metrum community! Our circuits and software reflect +NAR #88757, TRA #12200

Table of Contents

1. Introduction and Overview
2. Getting Started
2.1. Batteries
2.2. Ground Station Hardware
2.3. Linux/Mac/Windows Ground Station Software
2.4. Android Ground Station Software
3. Using Altus Metrum Hardware
3.1. Wiring and Electrical Interference
3.2. Hooking Up Lithium Polymer Batteries
3.3. Hooking Up Pyro Charges
3.4. Hooking Up a Power Switch
3.5. Understanding Beeps
3.6. Turning On the Power
3.7. Using an External Active Switch Circuit
3.8. Using a Separate Pyro Battery
3.9. Using a Different Kind of Battery
4. TeleMetrum
4.1. TeleMetrum Screw Terminals
4.2. Using a Separate Pyro Battery with TeleMetrum
4.3. Using an Active Switch with TeleMetrum
5. TeleMini
5.1. TeleMini v3 Screw Terminals
5.2. Using a Separate Pyro Battery with TeleMini v3
5.3. Using an Active Switch with TeleMini v3
5.4. TeleMini v1
6. EasyMini
6.1. EasyMini Screw Terminals
6.2. Connecting A Battery To EasyMini
6.3. Charging Lithium Batteries
6.4. Using a Separate Pyro Battery with EasyMini
6.5. Using an Active Switch with EasyMini
7. TeleMega
7.1. TeleMega Screw Terminals
7.2. Using a Separate Pyro Battery with TeleMega
7.3. Using Only One Battery With TeleMega
7.4. Using an Active Switch with TeleMega
8. EasyMega
8.1. EasyMega Screw Terminals
8.2. Using a Separate Pyro Battery with EasyMega
8.3. Using Only One Battery With EasyMega
8.4. Using an Active Switch with EasyMega
9. Installation
10. Using Altus Metrum Products
10.1. Being Legal
10.2. In the Rocket
10.3. On the Ground
10.4. Data Analysis
10.5. Future Plans
11. AltosUI
11.1. Monitor Flight
11.1.1. Launch Pad
11.1.2. Ascent
11.1.3. Descent
11.1.4. Landed
11.1.5. Table
11.1.6. Site Map
11.1.7. Igniter
11.2. Save Flight Data
11.3. Replay Flight
11.4. Graph Data
11.4.1. Flight Graph
11.4.2. Configure Graph
11.4.3. Flight Statistics
11.4.4. Map
11.5. Export Data
11.5.1. Comma Separated Value Format
11.5.2. Keyhole Markup Language (for Google Earth)
11.6. Configure Altimeter
11.6.1. Main Deploy Altitude
11.6.2. Apogee Delay
11.6.3. Apogee Lockout
11.6.4. Frequency
11.6.5. RF Calibration
11.6.6. Telemetry/RDF/APRS Enable
11.6.7. Telemetry baud rate
11.6.8. APRS Interval
11.6.9. APRS SSID
11.6.10. APRS Format
11.6.11. Callsign
11.6.12. Maximum Flight Log Size
11.6.13. Ignitor Firing Mode
11.6.14. Pad Orientation
11.6.15. Beeper Frequency
11.6.16. Logging Trigger Motion
11.6.17. Position Reporting Interval
11.6.18. Calibrate Accelerometer
11.6.19. Configure Pyro Channels
11.7. Configure AltosUI
11.7.1. Voice Settings
11.7.2. Log Directory
11.7.3. Callsign
11.7.4. Imperial Units
11.7.5. Serial Debug
11.7.6. Font size
11.7.7. Look & feel
11.7.8. Menu position
11.7.9. Map Cache Size
11.7.10. Manage Frequencies
11.8. Configure Groundstation
11.8.1. Frequency
11.8.2. RF Calibration
11.8.3. Telemetry Rate
11.9. Flash Image
11.10. Fire Igniter
11.11. Scan Channels
11.12. Load Maps
11.13. Monitor Idle
12. AltosDroid
12.1. Installing AltosDroid
12.2. Charging TeleBT Battery
12.3. Connecting to TeleBT over Bluetooth™
12.4. Connecting to TeleDongle or TeleBT over USB
12.5. AltosDroid Menu
12.6. Setup
12.7. Idle Mode
12.8. AltosDroid Flight Monitoring
12.9. Pad
12.10. Flight
12.11. Recover
12.12. Map
12.13. Downloading Flight Logs
A. System Operation
A.1. Firmware Modes
A.2. GPS
A.3. Controlling An Altimeter Over The Radio Link
A.4. Ground Testing
A.5. Radio Link
A.6. APRS
A.7. Configurable Parameters
B. Handling Precautions
C. Updating Device Firmware
C.1. Updating TeleMega, TeleMetrum v2, EasyMega, EasyMini or TeleDongle v3 Firmware
C.1.1. Recovering From Self-Flashing Failure
C.2. Pair Programming
C.2.1. Updating TeleMetrum v1.x Firmware
C.2.2. Updating TeleMini v1.0 Firmware
C.2.3. Updating TeleDongle v0.2 Firmware
D. Flight Data Recording
E. Altus Metrum Hardware Specifications
F. Release Notes
F.1. Release Notes for Version 1.8.4
F.1.1. AltOS
F.2. Release Notes for Version 1.8.3
F.2.1. AltOS
F.2.2. AltosUI and TeleGPS Applications
F.3. Release Notes for Version 1.8.2
F.3.1. AltOS
F.3.2. AltosUI and TeleGPS Applications
F.4. Release Notes for Version 1.8.1
F.4.1. AltOS
F.4.2. AltosUI and TeleGPS Applications
F.5. Release Notes for Version 1.8
F.5.1. AltOS
F.5.2. AltosUI and TeleGPS Applications
F.6. Release Notes for Version 1.7
F.6.1. AltOS
F.6.2. AltosUI and TeleGPS Applications
F.7. Release Notes for Version 1.6.8
F.7.1. AltOS
F.7.2. AltosUI, TeleGPS and AltosDroid Applications
F.8. Release Notes for Version 1.6.5
F.8.1. AltOS
F.8.2. AltosUI, TeleGPS and AltosDroid Applications
F.9. Release Notes for Version 1.6.4
F.9.1. AltOS
F.9.2. AltosUI, TeleGPS and AltosDroid Applications
F.9.3. Documentation
F.10. Release Notes for Version 1.6.3
F.10.1. AltOS
F.10.2. AltosUI and TeleGPS Applications
F.10.3. AltosDroid
F.10.4. Documentation
F.11. Release Notes for Version 1.6.2
F.11.1. AltOS
F.11.2. AltosUI and TeleGPS Applications
F.11.3. Documentation
F.12. Release Notes for Version 1.6.1
F.12.1. AltOS
F.12.2. AltosUI and TeleGPS Applications
F.12.3. AltosDroid
F.13. Release Notes for Version 1.6
F.13.1. AltOS
F.13.2. AltosUI and TeleGPS Applications
F.14. Release Notes for Version 1.5
F.14.1. AltOS
F.14.2. AltosUI and TeleGPS Applications
F.15. Release Notes for Version 1.4.2
F.15.1. AltosUI and TeleGPS Applications
F.16. Release Notes for Version 1.4.1
F.16.1. AltosUI and TeleGPS Applications:
F.17. Release Notes for Version 1.4
F.17.1. AltOS
F.17.2. AltosUI Application
F.17.3. TeleGPS Application
F.17.4. Documentation
F.18. Release Notes for Version 1.3.2
F.18.1. AltOS
F.18.2. AltosUI Application
F.19. Release Notes for Version 1.3.1
F.19.1. AltOS
F.19.2. AltosUI Application
F.20. Release Notes for Version 1.3
F.20.1. AltOS
F.20.2. AltosUI Application
F.21. Release Notes for Version 1.2.1
F.21.1. AltOS
F.21.2. AltosUI Application
F.21.3. AltosDroid
F.22. Release Notes for Version 1.2
F.22.1. AltOS
F.22.2. AltosUI and MicroPeak Application
F.23. Release Notes for Version 1.1
F.23.1. AltOS
F.23.2. AltosUI
F.24. Release Notes for Version 1.1
F.24.1. AltOS
F.24.2. AltosUI
F.25. Release Notes for Version 1.0.1
F.25.1. AltOS
F.25.2. AltosUI Application
F.26. Release Notes for Version 0.9.2
F.26.1. AltosUI
F.27. Release Notes for Version 0.9
F.27.1. AltOS
F.27.2. AltosUI Application
F.28. Release Notes for Version 0.8
F.28.1. AltosUI Application:
F.29. Release Notes for Version 0.7.1
F.29.1. AltosUI Application

List of Figures

4.1. TeleMetrum v2 Board
4.2. TeleMetrum v1 Board
5.1. TeleMini v3 Board
5.2. TeleMini v1 Board
6.1. EasyMini Board
7.1. TeleMega Board
8.1. EasyMega Board
11.1. AltosUI Main Window
11.2. Device Selection Dialog
11.3. Monitor Flight Launch Pad View
11.4. Monitor Flight Ascent View
11.5. Monitor Flight Descent View
11.6. Monitor Flight Landed View
11.7. Monitor Flight Table View
11.8. Monitor Flight Site Map View
11.9. Monitor Flight Additional Igniter View
11.10. Flight Data Graph
11.11. Flight Graph Configuration
11.12. Flight Statistics
11.13. Flight Map
11.14. Altimeter Configuration
11.15. Additional Pyro Channel Configuration
11.16. Configure AltosUI Dialog
11.17. Configure Groundstation Dialog
11.18. Fire Igniter Window
11.19. Scan Channels Window
11.20. Load Maps Window
11.21. Monitor Idle Window

List of Tables

3.1. AltOS Modes
3.2. Pad/Idle Indications
3.3. Pad Radio Indications
4.1. TeleMetrum Screw Terminals
5.1. TeleMini v3 Screw Terminals
6.1. EasyMini Screw Terminals
7.1. TeleMega Screw Terminals
8.1. EasyMega Screw Terminals
A.1. Altus Metrum APRS Comments
D.1. Data Storage on Altus Metrum altimeters
E.1. Altus Metrum Flight Computer Electronics
E.2. Altus Metrum Flight Computer Mechanical Components

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 releasing all of our hardware and software designs under open licenses, @@ -148,13 +148,13 @@ beeping that accompanies each mode. In the description of the beeping pattern, “dit” means a short beep while "dah" means a long beep (three times as long). “Brap” means -a long dissonant tone.

Table 3.1. AltOS Modes

Mode Name

Abbreviation

Beeps

Description

Startup

S

battery voltage in decivolts

Calibrating sensors, detecting orientation.

Idle

I

dit dit

Ready to accept commands over USB +a long dissonant tone.

Table 3.1. AltOS Modes

Mode Name

Abbreviation

Beeps

Description

Startup

S

battery voltage in decivolts

Calibrating sensors, detecting orientation.

Idle

I

dit dit

Ready to accept commands over USB or radio link.

Pad

P

dit dah dah dit

Waiting for launch. Not listening for commands.

Boost

B

dah dit dit dit

Accelerating upwards.

Fast

F

dit dit dah dit

Decelerating, but moving faster than 200m/s.

Coast

C

dah dit dah dit

Decelerating, moving slower than 200m/s

Drogue

D

dah dit dit

Descending after apogee. Above main height.

Main

M

dah dah

Descending. Below main height.

Landed

L

dit dah dit dit

Stable altitude for at least ten seconds.

Sensor error

X

dah dit dit dah

Error detected during sensor calibration.


Here’s a summary of all of the Pad and Idle mode indications. In Idle mode, you’ll hear one of these just once after the two short dits indicating idle mode. In Pad mode, after the dit dah dah dit indicating Pad mode, you’ll hear these once every five -seconds.

Table 3.2. Pad/Idle Indications

Name Beeps Description

Neither

brap

No continuity detected on either apogee or main igniters.

Apogee

dit

Continuity detected only on apogee igniter.

Main

dit dit

Continuity detected only on main igniter.

Both

dit dit dit

Continuity detected on both igniters.

Storage Full

warble

On-board data logging storage is full. This will +seconds.

Table 3.2. Pad/Idle Indications

Name Beeps Description

Neither

brap

No continuity detected on either apogee or main igniters.

Apogee

dit

Continuity detected only on apogee igniter.

Main

dit dit

Continuity detected only on main igniter.

Both

dit dit dit

Continuity detected on both igniters.

Storage Full

warble

On-board data logging storage is full. This will not prevent the flight computer from safely controlling the flight or transmitting telemetry signals, but no record of the flight will be @@ -166,7 +166,7 @@ primary igniter channels.


Table 3.3. Pad Radio Indications

Name Beeps Description

Neither

½ second tone

No continuity detected on either apogee or main igniters.

Apogee

dit

Continuity detected only on apogee igniter.

Main

dit dit

Continuity detected only on main igniter.

Both

dit dit dit

Continuity detected on both igniters.


During ascent, the tones will be muted to allow the +igniter status once every five seconds.

Table 3.3. Pad Radio Indications

Name Beeps Description

Neither

½ second tone

No continuity detected on either apogee or main igniters.

Apogee

dit

Continuity detected only on apogee igniter.

Main

dit dit

Continuity detected only on main igniter.

Both

dit dit dit

Continuity detected on both igniters.


During ascent, the tones will be muted to allow the telemetry data to consume the full radio bandwidth.

During descent and after landing, a ½ second tone will be transmitted every five seconds. This can be used to find the rocket using RDF techniques when the signal @@ -236,7 +236,7 @@ battery.

Chapter 4. TeleMetrum

Figure 4.1. TeleMetrum v2 Board

telemetrum-v2.0-th.jpg

Figure 4.2. TeleMetrum v1 Board

telemetrum-v1.1-thside.jpg

TeleMetrum is a 1 inch by 2¾ inch circuit board. It was designed to +the board.

Chapter 4. TeleMetrum

Figure 4.1. TeleMetrum v2 Board

telemetrum-v2.0-th.jpg

Figure 4.2. TeleMetrum v1 Board

telemetrum-v1.1-thside.jpg

TeleMetrum is a 1 inch by 2¾ inch circuit board. It was designed to fit inside coupler for 29mm air-frame tubing, but using it in a tube that small in diameter may require some creativity in mounting and wiring to succeed! The presence of an accelerometer means TeleMetrum should @@ -257,7 +257,7 @@ screw terminals in the same position.

Table 4.1. TeleMetrum Screw Terminals

Terminal #Terminal NameDescription

1

Switch Output

Switch connection to flight computer

2

Switch Input

Switch connection to positive battery terminal

3

Main +

Main pyro channel common connection to battery

4

Main -

Main pyro channel connection to pyro circuit

5

Apogee +

Apogee pyro channel common connection to battery

6

Apogee -

Apogee pyro channel connection to pyro circuit


4.2. Using a Separate Pyro Battery with TeleMetrum

As described above, using an external pyro battery involves +the terminals are as follows:

Table 4.1. TeleMetrum Screw Terminals

Terminal #Terminal NameDescription

1

Switch Output

Switch connection to flight computer

2

Switch Input

Switch connection to positive battery terminal

3

Main +

Main pyro channel common connection to battery

4

Main -

Main pyro channel connection to pyro circuit

5

Apogee +

Apogee pyro channel common connection to battery

6

Apogee -

Apogee pyro channel connection to pyro circuit


4.2. Using a Separate Pyro Battery with TeleMetrum

As described above, using an external pyro battery involves connecting the negative battery terminal to the flight computer ground, connecting the positive battery terminal to one of the igniter leads and connecting the other igniter @@ -273,7 +273,7 @@ connections, one to the positive battery terminal, one to the flight computer positive input and one to ground.

The positive battery terminal is available on screw terminal 2, the positive flight computer input is on terminal 1. To hook a lead to ground, solder a piece of wire, 24 to 28 -gauge stranded, to the GND hole just above terminal 1.

Chapter 5. TeleMini

Figure 5.1. TeleMini v3 Board

telemini-v3.0-top.jpg

telemini-v3.0-bottom.jpg

TeleMini v3 is 0.5 inches by 1.67 inches. It was +gauge stranded, to the GND hole just above terminal 1.

Chapter 5. TeleMini

Figure 5.1. TeleMini v3 Board

telemini-v3.0-top.jpg

telemini-v3.0-bottom.jpg

TeleMini v3 is 0.5 inches by 1.67 inches. It was designed to fit inside an 18mm air-frame tube, but using it in a tube that small in diameter may require some creativity in mounting and wiring to succeed! Since there is no @@ -291,7 +291,7 @@ screw terminals are located in the middle of the board for the power switch. Using the picture above and starting from the top for the pyro terminals and from the left for the power switch terminals, the -connections are as follows:

Table 5.1. TeleMini v3 Screw Terminals

Terminal #Terminal NameDescription

1

Apogee -

Apogee pyro channel connection to pyro circuit

2

Apogee

Apogee pyro channel common connection to battery

3

Main -

Main pyro channel connection to pyro circuit

4

Main

Main pyro channel common connection to battery

Left

Switch Output

Switch connection to flight computer

Right

Switch Input

Switch connection to positive battery terminal


5.2. Using a Separate Pyro Battery with TeleMini v3

As described above, using an external pyro battery involves +connections are as follows:

Table 5.1. TeleMini v3 Screw Terminals

Terminal #Terminal NameDescription

1

Apogee -

Apogee pyro channel connection to pyro circuit

2

Apogee

Apogee pyro channel common connection to battery

3

Main -

Main pyro channel connection to pyro circuit

4

Main

Main pyro channel common connection to battery

Left

Switch Output

Switch connection to flight computer

Right

Switch Input

Switch connection to positive battery terminal


5.2. Using a Separate Pyro Battery with TeleMini v3

As described above, using an external pyro battery involves connecting the negative battery terminal to the flight computer ground, connecting the positive battery terminal to one of the igniter leads and connecting the other igniter @@ -314,7 +314,7 @@ the left power switch wire. Hook a lead to either of the mounting holes for a ground connection.

5.4. TeleMini v1

TeleMini v1 is the earlier version of this product. It has a lower-power radio, less storage, no beeper and soldered-in wires instead of screw terminals for the -power switch.

Figure 5.2. TeleMini v1 Board

telemini-v1-top.jpg

Chapter 6. EasyMini

Figure 6.1. EasyMini Board

easymini-top.jpg

EasyMini is built on a 0.8 inch by 1½ inch circuit board. It’s +power switch.

Figure 5.2. TeleMini v1 Board

telemini-v1-top.jpg

Chapter 6. EasyMini

Figure 6.1. EasyMini Board

easymini-top.jpg

EasyMini is built on a 0.8 inch by 1½ inch circuit board. It’s designed to fit in a 24mm coupler tube.

You usually don’t need to configure EasyMini at all; it’s set up to do dual-deployment with an event at apogee to separate the airframe and deploy a drogue and another event at 250m @@ -325,7 +325,7 @@ board. Using the picture above, the top four have connections for the main pyro circuit and an external battery and the bottom four have connections for the apogee pyro circuit and the power -switch. Counting from the left, the connections are as follows:

Table 6.1. EasyMini Screw Terminals

Terminal #Terminal NameDescription

Top 1

Main -

Main pyro channel connection to pyro circuit

Top 2

Main

Main pyro channel common connection to battery

Top 3

Battery

Positive external battery terminal

Top 4

Battery -

Negative external battery terminal

Bottom 1

Apogee -

Apogee pyro channel connection to pyro circuit

Bottom 2

Apogee

Apogee pyro channel common connection to battery

Bottom 3

Switch Output

Switch connection to flight computer

Bottom 4

Switch Input

Switch connection to positive battery terminal


6.2. Connecting A Battery To EasyMini

There are two possible battery connections on +switch. Counting from the left, the connections are as follows:

Table 6.1. EasyMini Screw Terminals

Terminal #Terminal NameDescription

Top 1

Main -

Main pyro channel connection to pyro circuit

Top 2

Main

Main pyro channel common connection to battery

Top 3

Battery

Positive external battery terminal

Top 4

Battery -

Negative external battery terminal

Bottom 1

Apogee -

Apogee pyro channel connection to pyro circuit

Bottom 2

Apogee

Apogee pyro channel common connection to battery

Bottom 3

Switch Output

Switch connection to flight computer

Bottom 4

Switch Input

Switch connection to positive battery terminal


6.2. Connecting A Battery To EasyMini

There are two possible battery connections on EasyMini. You can use either method; both feed through the power switch terminals.

One battery connection is the standard Altus Metrum white JST plug. This mates with single-cell Lithium @@ -353,7 +353,7 @@ the flight computer positive input and one to ground. Use the negative external battery connection, top terminal 4 for ground.

The positive battery terminal is available on bottom terminal 4, the positive flight computer input is on the -bottom terminal 3.

Chapter 7. TeleMega

Figure 7.1. TeleMega Board

telemega-v1.0-top.jpg

TeleMega is a 1¼ inch by 3¼ inch circuit board. It was +bottom terminal 3.

Chapter 7. TeleMega

Figure 7.1. TeleMega Board

telemega-v1.0-top.jpg

TeleMega is a 1¼ inch by 3¼ inch circuit board. It was designed to easily fit in a 38mm coupler. Like TeleMetrum, TeleMega has an accelerometer and so it must be mounted so that the board is aligned with the flight axis. It can be mounted @@ -368,7 +368,7 @@ Radio switched from cc1120 to cc1200. they do mean that the device needs different firmware to operate correctly, so make sure you load the right firmware when reflashing the device.

7.1. TeleMega Screw Terminals

TeleMega has two sets of nine screw terminals on the end of -the board opposite the telemetry antenna. They are as follows:

Table 7.1. TeleMega Screw Terminals

Terminal #Terminal NameDescription

Top 1

Switch Input

Switch connection to positive battery terminal

Top 2

Switch Output

Switch connection to flight computer

Top 3

GND

Ground connection for use with external active switch

Top 4

Main -

Main pyro channel connection to pyro circuit

Top 5

Main

Main pyro channel common connection to battery

Top 6

Apogee -

Apogee pyro channel connection to pyro circuit

Top 7

Apogee

Apogee pyro channel common connection to battery

Top 8

D -

D pyro channel connection to pyro circuit

Top 9

D

D pyro channel common connection to battery

Bottom 1

GND

Ground connection for negative pyro battery terminal

Bottom 2

Pyro

Positive pyro battery terminal

Bottom 3

Lipo

Power switch output. Use to connect main battery to pyro battery input

Bottom 4

A -

A pyro channel connection to pyro circuit

Bottom 5

A

A pyro channel common connection to battery

Bottom 6

B -

B pyro channel connection to pyro circuit

Bottom 7

B

B pyro channel common connection to battery

Bottom 8

C -

C pyro channel connection to pyro circuit

Bottom 9

C

C pyro channel common connection to battery


7.2. Using a Separate Pyro Battery with TeleMega

TeleMega provides explicit support for an external pyro +the board opposite the telemetry antenna. They are as follows:

Table 7.1. TeleMega Screw Terminals

Terminal #Terminal NameDescription

Top 1

Switch Input

Switch connection to positive battery terminal

Top 2

Switch Output

Switch connection to flight computer

Top 3

GND

Ground connection for use with external active switch

Top 4

Main -

Main pyro channel connection to pyro circuit

Top 5

Main

Main pyro channel common connection to battery

Top 6

Apogee -

Apogee pyro channel connection to pyro circuit

Top 7

Apogee

Apogee pyro channel common connection to battery

Top 8

D -

D pyro channel connection to pyro circuit

Top 9

D

D pyro channel common connection to battery

Bottom 1

GND

Ground connection for negative pyro battery terminal

Bottom 2

Pyro

Positive pyro battery terminal

Bottom 3

Lipo

Power switch output. Use to connect main battery to pyro battery input

Bottom 4

A -

A pyro channel connection to pyro circuit

Bottom 5

A

A pyro channel common connection to battery

Bottom 6

B -

B pyro channel connection to pyro circuit

Bottom 7

B

B pyro channel common connection to battery

Bottom 8

C -

C pyro channel connection to pyro circuit

Bottom 9

C

C pyro channel common connection to battery


7.2. Using a Separate Pyro Battery with TeleMega

TeleMega provides explicit support for an external pyro battery. All that is required is to remove the jumper between the lipo terminal (Bottom 3) and the pyro terminal (Bottom 2). Then hook the negative pyro battery terminal to ground @@ -384,12 +384,12 @@ wire from the Lipo terminal (Bottom 3) to the Pyro terminal connections, one to the positive battery terminal, one to the flight computer positive input and one to ground.

The positive battery terminal is available on Top terminal 1, the positive flight computer input is on Top terminal -2. Ground is on Top terminal 3.

Chapter 8. EasyMega

Figure 8.1. EasyMega Board

easymega-v1.0-top.jpg

EasyMega is a 1¼ inch by 2¼ inch circuit board. It was +2. Ground is on Top terminal 3.

Chapter 8. EasyMega

Figure 8.1. EasyMega Board

easymega-v1.0-top.jpg

EasyMega is a 1¼ inch by 2¼ inch circuit board. It was designed to easily fit in a 38mm coupler. Like TeleMetrum, EasyMega has an accelerometer and so it must be mounted so that the board is aligned with the flight axis. It can be mounted either antenna up or down.

8.1. EasyMega Screw Terminals

EasyMega has two sets of nine screw terminals on the end of -the board opposite the telemetry antenna. They are as follows:

Table 8.1. EasyMega Screw Terminals

Terminal #Terminal NameDescription

Top 1

Switch Input

Switch connection to positive battery terminal

Top 2

Switch Output

Switch connection to flight computer

Top 3

GND

Ground connection for use with external active switch

Top 4

Main -

Main pyro channel connection to pyro circuit

Top 5

Main

Main pyro channel common connection to battery

Top 6

Apogee -

Apogee pyro channel connection to pyro circuit

Top 7

Apogee

Apogee pyro channel common connection to battery

Top 8

D -

D pyro channel connection to pyro circuit

Top 9

D

D pyro channel common connection to battery

Bottom 1

GND

Ground connection for negative pyro battery terminal

Bottom 2

Pyro

Positive pyro battery terminal

Bottom 3

Lipo

Power switch output. Use to connect main battery to pyro battery input

Bottom 4

A -

A pyro channel connection to pyro circuit

Bottom 5

A

A pyro channel common connection to battery

Bottom 6

B -

B pyro channel connection to pyro circuit

Bottom 7

B

B pyro channel common connection to battery

Bottom 8

C -

C pyro channel connection to pyro circuit

Bottom 9

C

C pyro channel common connection to battery


8.2. Using a Separate Pyro Battery with EasyMega

EasyMega provides explicit support for an external pyro +the board opposite the telemetry antenna. They are as follows:

Table 8.1. EasyMega Screw Terminals

Terminal #Terminal NameDescription

Top 1

Switch Input

Switch connection to positive battery terminal

Top 2

Switch Output

Switch connection to flight computer

Top 3

GND

Ground connection for use with external active switch

Top 4

Main -

Main pyro channel connection to pyro circuit

Top 5

Main

Main pyro channel common connection to battery

Top 6

Apogee -

Apogee pyro channel connection to pyro circuit

Top 7

Apogee

Apogee pyro channel common connection to battery

Top 8

D -

D pyro channel connection to pyro circuit

Top 9

D

D pyro channel common connection to battery

Bottom 1

GND

Ground connection for negative pyro battery terminal

Bottom 2

Pyro

Positive pyro battery terminal

Bottom 3

Lipo

Power switch output. Use to connect main battery to pyro battery input

Bottom 4

A -

A pyro channel connection to pyro circuit

Bottom 5

A

A pyro channel common connection to battery

Bottom 6

B -

B pyro channel connection to pyro circuit

Bottom 7

B

B pyro channel common connection to battery

Bottom 8

C -

C pyro channel connection to pyro circuit

Bottom 9

C

C pyro channel common connection to battery


8.2. Using a Separate Pyro Battery with EasyMega

EasyMega provides explicit support for an external pyro battery. All that is required is to remove the jumper between the lipo terminal (Bottom 3) and the pyro terminal (Bottom 2). Then hook the negative pyro battery terminal to ground @@ -558,7 +558,7 @@ feel free to dive in and help! Or let us know what you’d like to see that we aren’t already working on, and maybe we’ll get excited about it too…

Watch our web site for more news and information as our family of products -evolves!

Chapter 11. AltosUI

Figure 11.1. AltosUI Main Window

altosui.png

The AltosUI program provides a graphical user interface for +evolves!

Chapter 11. AltosUI

Figure 11.1. AltosUI Main Window

altosui.png

The AltosUI program provides a graphical user interface for interacting with the Altus Metrum product family. AltosUI can monitor telemetry data, configure devices and many other tasks. The primary interface window provides a selection of @@ -568,7 +568,7 @@ the tasks provided from the top-level toolbar.

Figure 11.2. Device Selection Dialog

device-selection.png

All telemetry data received are automatically recorded +device.

Figure 11.2. Device Selection Dialog

device-selection.png

All telemetry data received are automatically recorded in suitable log files. The name of the files includes the current date and rocket serial and flight numbers.

The radio frequency being monitored by the TeleDongle device is displayed at the top of the window. You can @@ -615,7 +615,7 @@ automatically switches to display data relevant to the current state of the flight. You can select other tabs at any time. The final table tab displays all of the raw telemetry values in one place in a -spreadsheet-like format.

11.1.1. Launch Pad

Figure 11.3. Monitor Flight Launch Pad View

launch-pad.png

The Launch Pad tab shows information used to decide when the +spreadsheet-like format.

11.1.1. Launch Pad

Figure 11.3. Monitor Flight Launch Pad View

launch-pad.png

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 whether the rocket is ready to launch:

@@ -673,7 +673,7 @@ GPS receiver has reliable reception from the satellites.

The Launchpad tab also shows the computed launch pad position and altitude, averaging many reported -positions to improve the accuracy of the fix.

11.1.2. Ascent

Figure 11.4. Monitor Flight Ascent View

ascent.png

This tab is shown during Boost, Fast and Coast +positions to improve the accuracy of the fix.

11.1.2. Ascent

Figure 11.4. Monitor Flight Ascent View

ascent.png

This tab is shown during Boost, Fast and Coast phases. The information displayed here helps monitor the rocket as it heads towards apogee.

The height, speed, acceleration and tilt are shown along with the maximum values for each of them. This allows you to @@ -684,7 +684,7 @@ may not get updated as the GPS receiver loses position fix. Once the rocket starts coasting, the receiver should start reporting position again.

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.

11.1.3. Descent

Figure 11.5. Monitor Flight Descent View

descent.png

Once the rocket has reached apogee and (we hope) +caused by wiring which comes loose under high acceleration.

11.1.3. Descent

Figure 11.5. Monitor Flight Descent View

descent.png

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, waiting for the main charge @@ -710,7 +710,7 @@ see what the status of the apogee charge is. Note that some commercial e-matches are designed to retain continuity even after being fired, and will continue to show as green or return from red to green after -firing.

11.1.4. Landed

Figure 11.6. Monitor Flight Landed View

landed.png

Once the rocket is on the ground, attention switches +firing.

11.1.4. Landed

Figure 11.6. Monitor Flight Landed View

landed.png

Once the rocket is on the ground, attention switches to recovery. While the radio signal is often lost once the rocket is on the ground, the last reported GPS position is generally within a short distance of the @@ -732,11 +732,11 @@ depends on the quality of your radio link and how many packets were received. Recovering the on-board data after flight may yield more precise results.

To get more detailed information about the flight, you can click on the Graph Flight button which will -bring up a graph window for the current flight.

11.1.5. Table

Figure 11.7. Monitor Flight Table View

table.png

The table view shows all of the data available from the +bring up a graph window for the current flight.

11.1.5. Table

Figure 11.7. Monitor Flight Table View

table.png

The table view shows all of the data available from the flight computer. Probably the most useful data on this tab is the detailed GPS information, which includes horizontal dilution of precision information, and -information about the signal being received from the satellites.

11.1.6. Site Map

Figure 11.8. Monitor Flight Site Map View

site-map.png

When the TeleMetrum has a GPS fix, the Site Map tab +information about the signal being received from the satellites.

11.1.6. Site Map

Figure 11.8. Monitor Flight Site Map View

site-map.png

When the TeleMetrum has 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 rocket’s state is @@ -755,7 +755,7 @@ units will be shown at the start of the line.

Images are fetched automatic Static API, and cached on disk for reuse. If map images cannot be downloaded, the rocket’s path will be traced on a dark gray background instead.

You can pre-load images for your favorite launch sites -before you leave home; check out Section 11.12, “Load Maps”.

11.1.7. Igniter

Figure 11.9. Monitor Flight Additional Igniter View

ignitor.png

TeleMega includes four additional programmable pyro +before you leave home; check out Section 11.12, “Load Maps”.

11.1.7. Igniter

Figure 11.9. Monitor Flight Additional Igniter View

ignitor.png

TeleMega includes four additional programmable pyro channels. The Ignitor tab shows whether each of them has continuity. If an ignitor has a low resistance, then the voltage measured here will be close to the pyro battery @@ -800,7 +800,7 @@ record file, either a .telem file recording telemetry data or a flash memory.

Note that telemetry files will generally produce poor graphs due to the lower sampling rate and missed telemetry packets. Use saved flight data in .eeprom files for graphing where possible.

Once a flight record is selected, a window with multiple tabs is -opened.

11.4.1. Flight Graph

Figure 11.10. Flight Data Graph

graph.png

By default, the graph contains acceleration (blue), +opened.

11.4.1. Flight Graph

Figure 11.10. Flight Data Graph

graph.png

By default, the graph contains acceleration (blue), velocity (green) and altitude (red).

The graph can be zoomed into a particular area by clicking and dragging down and to the right. Once zoomed, the graph can be reset by clicking and @@ -808,7 +808,7 @@ dragging up and to the left. Holding down control and clicking and dragging allows the graph to be panned. The right mouse button causes a pop-up menu to be displayed, giving you the option save or print the -plot.

11.4.2. Configure Graph

Figure 11.11. Flight Graph Configuration

graph-configure.png

This selects which graph elements to show, and, at the +plot.

11.4.2. Configure Graph

Figure 11.11. Flight Graph Configuration

graph-configure.png

This selects which graph elements to show, and, at the very bottom. It also lets you configure how the graph is drawn:

  • Whether to use metric or imperial units @@ -829,7 +829,7 @@ descent. Flight computers without accelerometers always compute both speed and acceleration from barometric data. A larger value smooths the data more. -

11.4.3. Flight Statistics

Figure 11.12. Flight Statistics

graph-stats.png

Shows overall data computed from the flight.

11.4.4. Map

Figure 11.13. Flight Map

graph-map.png

Shows a satellite image of the flight area overlaid +

11.4.3. Flight Statistics

Figure 11.12. Flight Statistics

graph-stats.png

Shows overall data computed from the flight.

11.4.4. Map

Figure 11.13. Flight Map

graph-map.png

Shows a satellite image of the flight area overlaid with the path of the flight. The red concentric circles mark the launch pad, the black concentric circles mark the landing location.

11.5. Export Data

This tool takes the raw data files and makes them @@ -856,7 +856,7 @@ standard units, with the barometric data reported in both pressure, altitude and height above pad units.

11.5.2. Keyhole Markup Language (for Google Earth)

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

11.6. Configure Altimeter

Figure 11.14. Altimeter Configuration

configure-altimeter.png

Select this button and then select either an altimeter or +in 3D.

11.6. Configure Altimeter

Figure 11.14. Altimeter Configuration

configure-altimeter.png

Select this button and then select either an altimeter or TeleDongle Device from the list provided. Selecting a TeleDongle device will use the radio link to configure a remote altimeter.

The first few lines of the dialog provide information about the @@ -1020,7 +1020,7 @@ flight computer with the antenna end, or end opposite the screw terminals, in the case of EasyMega, first up and then down.

When the calibration is complete, return to the Configure Altimeter window and save the new -calibration values.

11.6.19. Configure Pyro Channels

Figure 11.15. Additional Pyro Channel Configuration

configure-pyro.png

This opens a separate window to configure the +calibration values.

11.6.19. Configure Pyro Channels

Figure 11.15. Additional Pyro Channel Configuration

configure-pyro.png

This opens a separate window to configure the additional pyro channels available on TeleMega and EasyMega. One column is presented for each channel. Each row represents a single @@ -1147,7 +1147,7 @@ note that the check is based on when the rocket transitions

When a motor burns out, the rocket enters either Fast or Coast state (depending on how fast it is moving). If the computer detects upwards -acceleration again, it will move back to Boost state.

11.7. Configure AltosUI

Figure 11.16. Configure AltosUI Dialog

configure-altosui.png

This button presents a dialog so that you can +acceleration again, it will move back to Boost state.

11.7. Configure AltosUI

Figure 11.16. Configure AltosUI Dialog

configure-altosui.png

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

11.7.1. Voice Settings

AltosUI provides voice announcements during flight so that you can keep your eyes on the sky and still get information about the @@ -1212,7 +1212,7 @@ as you like, or even reconfigure the default set. Changing this list does not affect the frequency settings of any devices, it only changes the set of frequencies shown in the -menus.

11.8. Configure Groundstation

Figure 11.17. Configure Groundstation Dialog

configure-groundstation.png

Select this button and then select a TeleDongle or +menus.

11.8. Configure Groundstation

Figure 11.17. Configure Groundstation Dialog

configure-groundstation.png

Select this button and then select a TeleDongle or TeleBT Device from the list provided.

The first few lines of the dialog provide information about the connected device, including the product name, software version and hardware serial @@ -1267,7 +1267,7 @@ EasyMini and TeleDongle v3 are all programmed directly over USB (self programming). Please read the directions for flashing devices in -Appendix C, Updating Device Firmware.

11.10. Fire Igniter

Figure 11.18. Fire Igniter Window

fire-igniter.png

This activates the igniter circuits in the flight +Appendix C, Updating Device Firmware.

11.10. Fire Igniter

Figure 11.18. Fire Igniter Window

fire-igniter.png

This activates the igniter circuits in the flight computer to help test recovery systems deployment. Because this command can operate over the @@ -1283,13 +1283,13 @@ button. The word Arm is replaced by a cou timer indicating that 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.

11.11. Scan Channels

Figure 11.19. Scan Channels Window

scan-channels.png

This listens for telemetry packets on all of the +igniter.

11.11. Scan Channels

Figure 11.19. Scan Channels Window

scan-channels.png

This listens for telemetry packets on all of the configured frequencies, displaying information about each device it receives a packet from. You can select which of the baud rates and telemetry formats should be tried; by default, it only listens at 38400 baud with the standard telemetry format used in v1.0 and -later firmware.

11.12. Load Maps

Figure 11.20. Load Maps Window

load-maps.png

Before heading out to a new launch site, you can use +later firmware.

11.12. Load Maps

Figure 11.20. Load Maps Window

load-maps.png

Before heading out to a new launch site, you can use this to load satellite images in case you don’t have internet connectivity at the site.

There’s a drop-down menu of launch sites we know about; if your favorites aren’t there, please let us @@ -1337,7 +1337,7 @@ Google Maps; note that Google limits how many images you can fetch at once, so if you load more than one launch site, you may get some gray areas in the map which indicate that Google is tired of sending data to -you. Try again later.

11.13. Monitor Idle

Figure 11.21. Monitor Idle Window

monitor-idle.png

This brings up a dialog similar to the Monitor Flight +you. Try again later.

11.13. Monitor Idle

Figure 11.21. Monitor Idle Window

monitor-idle.png

This brings up a dialog similar to the Monitor Flight UI, except it works with the altimeter in “idle” mode by sending query commands to discover the current state rather than listening for telemetry @@ -1950,7 +1950,7 @@ same time while keeping the identify of each one separate in the receiver. By default, the SSID is set to the last digit of the device serial number.

The APRS packet format includes a comment field that can have arbitrary text in it. AltOS uses this to send -status information as shown in the following table.

Table A.1. Altus Metrum APRS Comments

Field Example Description

1

L

GPS Status U for unlocked, L for locked

2

6

Number of Satellites in View

3

B4.0

Altimeter Battery Voltage

4

A3.7

Apogee Igniter Voltage

5

M3.7

Main Igniter Voltage

6

1286

Device Serial Number

4

1286

Device Serial Number


Here’s an example of an APRS comment showing GPS lock with 6 +status information as shown in the following table.

Table A.1. Altus Metrum APRS Comments

Field Example Description

1

L

GPS Status U for unlocked, L for locked

2

6

Number of Satellites in View

3

B4.0

Altimeter Battery Voltage

4

A3.7

Apogee Igniter Voltage

5

M3.7

Main Igniter Voltage

6

1286

Device Serial Number

4

1286

Device Serial Number


Here’s an example of an APRS comment showing GPS lock with 6 satellites in view, a primary battery at 4.0V, and apogee and main igniters both at 3.7V from device 1286.

L6 B4.0 A3.7 M3.7 1286

Here’s an example of an APRS comment showing GPS lock with 6 satellites in view and a primary battery at 4.0V from device 1876.

L6 B4.0 1876

Make sure your primary battery is above 3.8V @@ -2303,7 +2303,7 @@ descent, except for TeleMini v1.0, which records ascent at 10 samples per second and descent at 1 sample per second. Data are logged to an on-board flash memory part, which can be partitioned into -several equal-sized blocks, one for each flight.

Table D.1. Data Storage on Altus Metrum altimeters

Device Bytes per Sample Total Storage Minutes at Full Rate

TeleMetrum v1.0

8

1MB

20

TeleMetrum v1.1 v1.2

8

2MB

40

TeleMetrum v2.0

16

8MB

80

TeleMini v1.0

2

5kB

4

TeleMini v3.0

16

512kB

5

EasyMini

16

1MB

10

TeleMega

32

8MB

40

EasyMega

32

8MB

40


The on-board flash is partitioned into separate flight logs, +several equal-sized blocks, one for each flight.

Table D.1. Data Storage on Altus Metrum altimeters

Device Bytes per Sample Total Storage Minutes at Full Rate

TeleMetrum v1.0

8

1MB

20

TeleMetrum v1.1 v1.2

8

2MB

40

TeleMetrum v2.0

16

8MB

80

TeleMini v1.0

2

5kB

4

TeleMini v3.0

16

512kB

5

EasyMini

16

1MB

10

TeleMega

32

8MB

40

EasyMega

32

8MB

40


The on-board flash is partitioned into separate flight logs, each of a fixed maximum size. Increase the maximum size of each log and you reduce the number of flights that can be stored. Decrease the size and you can store more flights.

Configuration data is also stored in the flash memory on @@ -2332,11 +2332,13 @@ flight data, so be sure to download flight data and erase it from the flight computer before it fills up. The flight computer will still successfully control the flight even if it cannot log data, so the only thing you will lose is the data.

Appendix E. Altus Metrum Hardware Specifications

Here’s the full set of Altus Metrum products, both in -production and retired.

Table E.1. Altus Metrum Flight Computer Electronics

Device Barometer Z-axis accel GPS 3D sensors Storage RF Output Battery

TeleMetrum v1.0

MP3H6115 10km (33k')

MMA2202 50g

SkyTraq

-

1MB

10mW

3.7V

TeleMetrum v1.1

MP3H6115 10km (33k')

MMA2202 50g

SkyTraq

-

2MB

10mW

3.7V

TeleMetrum v1.2

MP3H6115 10km (33k')

ADXL78 70g

SkyTraq

-

2MB

10mW

3.7V

TeleMetrum v2.0

MS5607 30km (100k')

MMA6555 102g

uBlox Max-7Q

-

8MB

40mW

3.7V

TeleMini v1.0

MP3H6115 10km (33k')

-

-

-

5kB

10mW

3.7V

TeleMini v3.0

MS5607 30km (100k')

-

-

-

512kB

40mW

3.7V

EasyMini v1.0

MS5607 30km (100k')

-

-

-

1MB

-

3.7-12V

TeleMega v1.0

MS5607 30km (100k')

MMA6555 102g

uBlox Max-7Q

MPU6000 HMC5883

8MB

40mW

3.7V

TeleMega v2.0

MS5607 30km (100k')

MMA6555 102g

uBlox Max-7Q

MPU6000 HMC5883

8MB

40mW

3.7V

EasyMega v1.0

MS5607 30km (100k')

MMA6555 102g

-

MPU6000 HMC5883

8MB

-

3.7V


Table E.2. Altus Metrum Flight Computer Mechanical Components

DeviceConnectorsScrew TerminalsWidthLengthTube Size

TeleMetrum

Antenna Debug Companion USB Battery

Apogee pyro Main pyro Switch

1 inch (2.54cm)

2 ¾ inch (6.99cm)

29mm coupler

TeleMini v1.0

Antenna Debug Battery

Apogee pyro Main pyro

½ inch (1.27cm)

1½ inch (3.81cm)

18mm coupler

TeleMini v2.0

Antenna Debug USB Battery

Apogee pyro Main pyro Battery Switch

0.8 inch (2.03cm)

1½ inch (3.81cm)

24mm coupler

EasyMini

Debug USB Battery

Apogee pyro Main pyro Battery

0.8 inch (2.03cm)

1½ inch (3.81cm)

24mm coupler

TeleMega

Antenna Debug Companion USB Battery

Apogee pyro Main pyro Pyro A-D Switch Pyro battery

1¼ inch (3.18cm)

3¼ inch (8.26cm)

38mm coupler

EasyMega

Debug Companion USB Battery

Apogee pyro Main pyro Pyro A-D Switch Pyro battery

1¼ inch (3.18cm)

2¼ inch (5.62cm)

38mm coupler


Appendix F. Release Notes

F.1. Release Notes for Version 1.8.3

Version 1.8.3 includes support for TeleMega version 3.0 along +production and retired.

Table E.1. Altus Metrum Flight Computer Electronics

Device Barometer Z-axis accel GPS 3D sensors Storage RF Output Battery

TeleMetrum v1.0

MP3H6115 10km (33k')

MMA2202 50g

SkyTraq

-

1MB

10mW

3.7V

TeleMetrum v1.1

MP3H6115 10km (33k')

MMA2202 50g

SkyTraq

-

2MB

10mW

3.7V

TeleMetrum v1.2

MP3H6115 10km (33k')

ADXL78 70g

SkyTraq

-

2MB

10mW

3.7V

TeleMetrum v2.0

MS5607 30km (100k')

MMA6555 102g

uBlox Max-7Q

-

8MB

40mW

3.7V

TeleMini v1.0

MP3H6115 10km (33k')

-

-

-

5kB

10mW

3.7V

TeleMini v3.0

MS5607 30km (100k')

-

-

-

512kB

40mW

3.7V

EasyMini v1.0

MS5607 30km (100k')

-

-

-

1MB

-

3.7-12V

TeleMega v1.0

MS5607 30km (100k')

MMA6555 102g

uBlox Max-7Q

MPU6000 HMC5883

8MB

40mW

3.7V

TeleMega v2.0

MS5607 30km (100k')

MMA6555 102g

uBlox Max-7Q

MPU6000 HMC5883

8MB

40mW

3.7V

EasyMega v1.0

MS5607 30km (100k')

MMA6555 102g

-

MPU6000 HMC5883

8MB

-

3.7V


Table E.2. Altus Metrum Flight Computer Mechanical Components

DeviceConnectorsScrew TerminalsWidthLengthTube Size

TeleMetrum

Antenna Debug Companion USB Battery

Apogee pyro Main pyro Switch

1 inch (2.54cm)

2 ¾ inch (6.99cm)

29mm coupler

TeleMini v1.0

Antenna Debug Battery

Apogee pyro Main pyro

½ inch (1.27cm)

1½ inch (3.81cm)

18mm coupler

TeleMini v2.0

Antenna Debug USB Battery

Apogee pyro Main pyro Battery Switch

0.8 inch (2.03cm)

1½ inch (3.81cm)

24mm coupler

EasyMini

Debug USB Battery

Apogee pyro Main pyro Battery

0.8 inch (2.03cm)

1½ inch (3.81cm)

24mm coupler

TeleMega

Antenna Debug Companion USB Battery

Apogee pyro Main pyro Pyro A-D Switch Pyro battery

1¼ inch (3.18cm)

3¼ inch (8.26cm)

38mm coupler

EasyMega

Debug Companion USB Battery

Apogee pyro Main pyro Pyro A-D Switch Pyro battery

1¼ inch (3.18cm)

2¼ inch (5.62cm)

38mm coupler


Appendix F. Release Notes

F.1. Release Notes for Version 1.8.4

Version 1.8.4 includes support for EasyMini version 2.0

F.1.1. AltOS

  • +Support for EasyMini version 2.0 hardware. +

F.2. Release Notes for Version 1.8.3

Version 1.8.3 includes support for TeleMega version 3.0 along with two important flight computer fixes. This version also changes KML export data to make Tripoli Record reporting better and some updates to graph presentation and data -downloading.

F.1.1. AltOS

AltOS New Features

  • +downloading.

    F.2.1. AltOS

    AltOS New Features

    • Support for TeleMega version 3.0 hardware.

    AltOS Bug Fixes

    • Ground testing EasyMega and TeleMega additional pyro @@ -2348,7 +2350,7 @@ from capturing log data.
    • Fixed saving of pyro configuration that ended with Descending. -

    F.1.2. AltosUI and TeleGPS Applications

    AltosUI New Features

    • +

    F.2.2. AltosUI and TeleGPS Applications

    AltosUI New Features

    • Support for TeleMega version 3.0.
    • Graph lines have improved appearance to make them easier to @@ -2372,18 +2374,18 @@ to make it more useful for Tripoli record reporting.
    • CSV export now includes TeleMega/EasyMega pyro voltages and tilt angle. -

F.2. Release Notes for Version 1.8.2

Version 1.8.2 includes support for TeleGPS version 2.0 along +

F.3. Release Notes for Version 1.8.2

Version 1.8.2 includes support for TeleGPS version 2.0 along with accelerometer recalibration support in AltosUI.

1.8.2 also contains a couple of minor fixes for AltosUI when -analyzing saved data files.

F.2.1. AltOS

AltOS New Features

  • +analyzing saved data files.

    F.3.1. AltOS

    AltOS New Features

    • Support for TeleGPS version 2.0 hardware. -

    F.2.2. AltosUI and TeleGPS Applications

    AltosUI and TeleGPS New Features

    • +

    F.3.2. AltosUI and TeleGPS Applications

    AltosUI and TeleGPS New Features

    • Support for TeleGPS version 2.0.
    • Accelerometer re-calibration user interface.

    AltosUI and TeleGPS Bug Fixes

    • Prevent some crashes when reading older saved flight data for graphing or KML export. -

F.3. Release Notes for Version 1.8.1

Version 1.8.1 includes an important bug fix for Apogee Lockout +

F.4. Release Notes for Version 1.8.1

Version 1.8.1 includes an important bug fix for Apogee Lockout operation in all flight computers. Anyone using this option must update firmware.

This release also contains a change in how flight computers with accelerometers deal with speeds around and above Mach @@ -2393,7 +2395,7 @@ disregard the barometric sensor above 330m/s (around Mach effect without ever going away entirely. This prevents early drogue deployment for flights which spend considerable time above Mach 1.

1.8.1 also contains a couple of minor fixes for AltosUI when -analyzing saved data files.

F.3.1. AltOS

AltOS Bug Fixes

  • +analyzing saved data files.

    F.4.1. AltOS

    AltOS Bug Fixes

    • Handle time value wrapping in Apogee Lockout correctly. Without this, apogee lockout would sometimes prevent any drogue charge from firing. @@ -2402,7 +2404,7 @@ Change Kalman filter on flight computers with accelerometer to continue using the barometric sensor even at high speeds to avoid unintentional drogue deployment during deceleration. -

    F.3.2. AltosUI and TeleGPS Applications

    AltosUI New Features

    • +

    F.4.2. AltosUI and TeleGPS Applications

    AltosUI New Features

    • Add new Huge font size to make text even bigger on high resolution monitors.

    AltosUI Bug Fixes

    • @@ -2411,12 +2413,12 @@ for graphing or KML export.
    • Load frequency preference at startup. The loading code was broken, so you’d see only the default frequencies. -

F.4. Release Notes for Version 1.8

Version 1.8 includes support for our new TeleBT v4.0 ground +

F.5. Release Notes for Version 1.8

Version 1.8 includes support for our new TeleBT v4.0 ground station, updates for data analysis in our ground station software and bug fixes in in the flight software for all our -boards and ground station interfaces.

F.4.1. AltOS

AltOS New Features

  • +boards and ground station interfaces.

    F.5.1. AltOS

    AltOS New Features

    • Add support for TeleBT v4.0 boards. -

    F.4.2. AltosUI and TeleGPS Applications

    AltosUI New Features

    • +

    F.5.2. AltosUI and TeleGPS Applications

    AltosUI New Features

    • Add support for TeleBT v4.0 hardware
    • Rewrite graphing and export functions. This code now handles @@ -2427,20 +2429,20 @@ acceleration data more accurate.

    AltosUI Bug Fixes

    • Correct axis labeling of magnetic sensor in TeleMega and EasyMega. The Y and Z axes were flipped. -

F.5. Release Notes for Version 1.7

Version 1.7 includes support for our new TeleMini v3.0 +

F.6. Release Notes for Version 1.7

Version 1.7 includes support for our new TeleMini v3.0 flight computer and bug fixes in in the flight software for all our boards -and ground station interfaces.

F.5.1. AltOS

AltOS New Features

  • +and ground station interfaces.

    F.6.1. AltOS

    AltOS New Features

    • Add support for TeleMini v3.0 boards.

    AltOS Fixes

    • Fix interrupt priorities on STM32L processors. Run timer interrupt at lowest priority so that device interrupts get serviced first. -

    F.5.2. AltosUI and TeleGPS Applications

    AltosUI New Features

    • +

    F.6.2. AltosUI and TeleGPS Applications

    AltosUI New Features

    • Add support for TeleMini v3.0 hardware -

F.6. Release Notes for Version 1.6.8

Version 1.6.8 fixes a TeleMega and TeleMetrum v2.0 bug where +

F.7. Release Notes for Version 1.6.8

Version 1.6.8 fixes a TeleMega and TeleMetrum v2.0 bug where the device could stop logging data and transmitting telemetry in flight. All TeleMega v1.0, v2.0 and TeleMetrum -v2.0 users should update their flight firmware.

F.6.1. AltOS

AltOS fixes:

  • +v2.0 users should update their flight firmware.

    F.7.1. AltOS

    AltOS fixes:

    • Fix STM32L DMA driver to work around STM32L SoC DMA priority issue t lock-up in the logging or radio code, either of which could stop data logging and telemetry. @@ -2453,7 +2455,7 @@ flight.

    AltOS changes:

    • Flash LEDS on all products briefly during power up so that they can be tested during production. -

    F.6.2. AltosUI, TeleGPS and AltosDroid Applications

    AltosUI fixes:

    • +

    F.7.2. AltosUI, TeleGPS and AltosDroid Applications

    AltosUI fixes:

    • Re-enable go/no-go entries after they’ve been disabled due to lack of data. If telemetry information is delayed when the Ui starts up, sometimes important fields would get @@ -2461,20 +2463,20 @@ disabled to never re-appear.
    • Deal with ground station failure better during Configure Ground Station operation by cleaning up pending operations. -

F.7. Release Notes for Version 1.6.5

Version 1.6.5 fixes a TeleMega and TeleMetrum v2.0 bug where +

F.8. Release Notes for Version 1.6.5

Version 1.6.5 fixes a TeleMega and TeleMetrum v2.0 bug where the device would often stop logging data and transmitting telemetry in flight. All TeleMega v1.0, v2.0 and TeleMetrum -v2.0 users should update their flight firmware.

F.7.1. AltOS

AltOS fixes:

  • +v2.0 users should update their flight firmware.

    F.8.1. AltOS

    AltOS fixes:

    • Fix STM32L SPI driver to prevent lock-up in the logging or radio code, either of which could stop data logging and telemetry. Found and characterized by Chuck Haskin, who also tested the new firmware before release. -

    F.7.2. AltosUI, TeleGPS and AltosDroid Applications

    AltosUI fixes:

    • +

    F.8.2. AltosUI, TeleGPS and AltosDroid Applications

    AltosUI fixes:

    • Deliver firmward for TeleMega v2.0 and TeleBT v3.0 with Windows package. -

F.8. Release Notes for Version 1.6.4

Version 1.6.4 fixes a bluetooth communication problem with +

F.9. Release Notes for Version 1.6.4

Version 1.6.4 fixes a bluetooth communication problem with TeleBT v1.0 devices, along with some altosui and altosdroid -minor nits. It also now ships firmware for some newer devices.

F.8.1. AltOS

AltOS fixes:

  • +minor nits. It also now ships firmware for some newer devices.

    F.9.1. AltOS

    AltOS fixes:

    • Fix hardware flow control on TeleBT v1.0. Hardware RTS/CTS doesn’t seem to work, switch from using the hardware to driving these pins with software. @@ -2482,7 +2484,7 @@ driving these pins with software. Fix ARM USB drivers to deal with OS restarts. Needed to reset all USB-related state when the USB bus is reset. These fixes affect all STM32L, STM32F0 and LPC11U14 based devices. -

    F.8.2. AltosUI, TeleGPS and AltosDroid Applications

    AltosUI, TeleGPS and AltosDroid New Features:

    • +

    F.9.2. AltosUI, TeleGPS and AltosDroid Applications

    AltosUI, TeleGPS and AltosDroid New Features:

    • Automatically switch from meters or feet to kilometers or miles for distance units.
    • @@ -2493,17 +2495,17 @@ Abort map preloading when the preload map dialog is closed. In AltosDroid, Don’t reconnect to last device if the user had disconnected it the last time the application was active. -

    F.8.3. Documentation

    • +

    F.9.3. Documentation

    • Mention TeleMega v2.0 in hardware specs table.
    • Document TeleGPS RF output in telegps manual. -

F.9. Release Notes for Version 1.6.3

Version 1.6.3 adds idle mode to AltosDroid and has bug fixes +

F.10. Release Notes for Version 1.6.3

Version 1.6.3 adds idle mode to AltosDroid and has bug fixes for our host software on desktops, laptops an android devices -along with BlueTooth support for Windows.

F.9.1. AltOS

AltOS fixes:

  • +along with BlueTooth support for Windows.

    F.10.1. AltOS

    AltOS fixes:

    • Fix hardware flow control on TeleBT v3.0. RTS/CTS is wired backwards on this board, switch from using the hardware to driving these pins with software. -

    F.9.2. AltosUI and TeleGPS Applications

    AltosUI and TeleGPS New Features:

    • +

    F.10.2. AltosUI and TeleGPS Applications

    AltosUI and TeleGPS New Features:

    • Add BlueTooth support for Windows operating system. This supports connections to TeleBT over BlueTooth rather than just USB. @@ -2525,7 +2527,7 @@ the connected Altus Metrum USB devices appear again.
    • Fix acceleration data presented in MonitorIdle mode for TeleMetrum v2.0 flight computers. -

    F.9.3. AltosDroid

    AltosDroid new features:

    • +

    F.10.3. AltosDroid

    AltosDroid new features:

    • Monitor Idle mode. Check state of flight computer while in idle mode over the radio link
    • @@ -2563,12 +2565,12 @@ Recover old tracker positions when restarting application. This finally allows you to safely stop and restart the application without losing the last known location of any tracker. -

    F.9.4. Documentation

    • +

    F.10.4. Documentation

    • Document TeleMega and EasyMega additional pyro channel continuity audio alert pattern. -

F.10. Release Notes for Version 1.6.2

Version 1.6.2 includes support for our updated TeleMega v2.0 +

F.11. Release Notes for Version 1.6.2

Version 1.6.2 includes support for our updated TeleMega v2.0 product and bug fixes in in the flight software for all our boards -and ground station interfaces.

F.10.1. AltOS

AltOS New Features:

  • +and ground station interfaces.

    F.11.1. AltOS

    AltOS New Features:

    • Add support for TeleMega v2.0 boards.
    • Add PWM servo driver. There’s no higher level code using @@ -2577,14 +2579,14 @@ servo output connector.

    AltOS Fixes:

    • Slow down telemetry packets to allow receiver to keep up. -

    F.10.2. AltosUI and TeleGPS Applications

    AltosUI and TeleGPS Fixes:

    • +

    F.11.2. AltosUI and TeleGPS Applications

    AltosUI and TeleGPS Fixes:

    • Fix post-flight orientation computation when processing TeleMega and EasyMega eeprom data files.
    • Capture complete eeprom data even when there are invalid entries in the data. This keeps reading eeprom contents and writing the associated .eeprom file when an error is detected. -

    F.10.3. Documentation

    We spent a bunch of time trying to improve our documentation

    • +

    F.11.3. Documentation

    We spent a bunch of time trying to improve our documentation

    • HTML versions now have a table of contents on the left side.
    • EasyMini now has its own shorter manual. @@ -2593,9 +2595,9 @@ Provide links between sections in each document.
    • Lots of minor rewriting and restructuring to avoid duplication of information -

F.11. Release Notes for Version 1.6.1

Version 1.6.1 includes support for our updated TeleBT v3.0 +

F.12. Release Notes for Version 1.6.1

Version 1.6.1 includes support for our updated TeleBT v3.0 product and bug fixes in in the flight software for all our boards -and ground station interfaces.

F.11.1. AltOS

AltOS New Features:

  • +and ground station interfaces.

    F.12.1. AltOS

    AltOS New Features:

    • Add support for TeleBT v3.0 boards.
    • Add support for uncompressed APRS data, providing support @@ -2605,7 +2607,7 @@ altitude data.

    AltOS Fixes:

    • Make TeleDongle and TeleBT more tolerant of data rate variations from transmitting devices. -

    F.11.2. AltosUI and TeleGPS Applications

    AltosUI and TeleGPS New Features:

    • +

    F.12.2. AltosUI and TeleGPS Applications

    AltosUI and TeleGPS New Features:

    • Add map to Monitor Idle display. It’s nice to be able to verify that maps are working, instead of needing to use Monitor Flight. @@ -2643,7 +2645,7 @@ will take longer to respond to changes now.
    • Make Replay Flight run in realtime again. It had been set to run at 10x speed by mistake. -

    F.11.3. AltosDroid

    AltosDroid New Features:

    • +

    F.12.3. AltosDroid

    AltosDroid New Features:

    • Add offline map support using mapping code from AltosUI.
    • Support TeleDongle (and TeleBT via USB) on devices @@ -2671,9 +2673,9 @@ Make voice announcements depend on current tab.
    • Compute adjustment to current travel direction while in motion towards rocket. -

F.12. Release Notes for Version 1.6

Version 1.6 includes support for our updated TeleDongle v3.0 +

F.13. Release Notes for Version 1.6

Version 1.6 includes support for our updated TeleDongle v3.0 product and bug fixes in in the flight software for all our boards -and ground station interfaces.

F.12.1. AltOS

AltOS New Features

  • +and ground station interfaces.

    F.13.1. AltOS

    AltOS New Features

    • Add support for TeleDongle v3.0 boards.

    AltOS Fixes

    • Don’t beep out the continuity twice by accident in idle mode. @@ -2693,7 +2695,7 @@ interrupt code would occasionally wedge on long transfers if interrupts were blocked for too long. This affects all released TeleGPS products; if you have a TeleGPS device, you’ll want to reflash the firmware. -

    F.12.2. AltosUI and TeleGPS Applications

    AltosUI and TeleGPS New Features

    • +

    F.13.2. AltosUI and TeleGPS Applications

    AltosUI and TeleGPS New Features

    • Compute tilt angle from TeleMega and EasyMega log files. This duplicates the quaternion-based angle tracking code from the flight firmware inside the ground station @@ -2739,9 +2741,9 @@ five seconds these days. In the Scan Channels code, reset pending flight state information each time we change channels. This avoids having flight computers appear on multiple frequencies by accident. -

F.13. Release Notes for Version 1.5

Version 1.5 is a major release. It includes support for our new +

F.14. Release Notes for Version 1.5

Version 1.5 is a major release. It includes support for our new EasyMega product, new features and bug fixes in in the flight -software for all our boards and the AltosUI ground station

F.13.1. AltOS

AltOS New Features

  • +software for all our boards and the AltosUI ground station

    F.14.1. AltOS

    AltOS New Features

    • Add support for EasyMega boards.
    • Make the APRS SSID be configurable. This lets you track @@ -2775,7 +2777,7 @@ the delay, but become bad before the delay expires. Allow negative numbers in pyro configuration values. This lets you specify things like descending speed or deceleration. -

    F.13.2. AltosUI and TeleGPS Applications

    AltosUI and TeleGPS New Features

    • +

    F.14.2. AltosUI and TeleGPS Applications

    AltosUI and TeleGPS New Features

    • Support telemetry baud rate selection. Adds menus to the flight monitoring and configuration for baud rate selection. @@ -2792,18 +2794,18 @@ Make the Graph button on the landed tab w Make tests for Java on Windows a bit smarter, and also provide the user with the option to skip installing Java for cases where we just can’t figure out what version is installed. -

F.14. Release Notes for Version 1.4.2

Version 1.4.2 is a minor release. It fixes Java-related install issues on -Windows

F.14.1. AltosUI and TeleGPS Applications

Windows Install Fixes

  • +

F.15. Release Notes for Version 1.4.2

Version 1.4.2 is a minor release. It fixes Java-related install issues on +Windows

F.15.1. AltosUI and TeleGPS Applications

Windows Install Fixes

  • Checks for Java installation data in more registry locations.
  • Allows user to bypass Java installation in case the detection fails. -

F.15. Release Notes for Version 1.4.1

Version 1.4.1 is a minor release. It fixes install issues on +

F.16. Release Notes for Version 1.4.1

Version 1.4.1 is a minor release. It fixes install issues on Windows and provides the missing TeleMetrum V2.0 firmware. There aren’t any changes to the firmware or host applications at all. All Windows users will want to upgrade to get the signed driver, but Mac and Linux users who do not need the TeleMetrum -V2.0 firmware image will not need to upgrade.

F.15.1. AltosUI and TeleGPS Applications:

Windows Install Fixes

  • +V2.0 firmware image will not need to upgrade.

    F.16.1. AltosUI and TeleGPS Applications:

    Windows Install Fixes

    • Provide signed Windows driver files. This should avoid any need to disable driver signature checking on Windows 7 or 8.
    • @@ -2821,9 +2823,9 @@ packages for Linux, Mac and Windows. Include Google Application Key for map downloading. The 1.4 release didn’t have this key in the released version of the software, making map downloading fail for most people. -

F.16. Release Notes for Version 1.4

Version 1.4 is a major release. It includes support for our new +

F.17. Release Notes for Version 1.4

Version 1.4 is a major release. It includes support for our new TeleGPS product, new features and bug fixes in in the flight -software for all our boards and the AltosUI ground station

F.16.1. AltOS

AltOS new features:

  • +software for all our boards and the AltosUI ground station

    F.17.1. AltOS

    AltOS new features:

    • Add support for TeleGPS boards.
    • Make the beeper tone configurable, making it @@ -2853,7 +2855,7 @@ number to 2 on TeleMega and TeleMetrum v2.
    • Fix u-Blox GPS driver to mark course and speed data as being present. -

    F.16.2. AltosUI Application

    AltosUI new features:

    • +

    F.17.2. AltosUI Application

    AltosUI new features:

    • Add zooming and new content types (terrain and road maps) to map view. Change map storage format from PNG to Jpeg, which saves a huge amount of disk @@ -2910,12 +2912,12 @@ Handle TeleMetrum and TeleMini eeprom files generated with pre-1.0 firmware. Those ancient versions didn’t report the log format, so just use the product name instead. -

    F.16.3. TeleGPS Application

    • +

    F.17.3. TeleGPS Application

    • New application designed for use with TeleGPS boards.
    • Shares code with AltosUI, mostly just trimmed down to focus on TeleGPS-related functions. -

    F.16.4. Documentation

    Documentation changes:

    • +

    F.17.4. Documentation

    Documentation changes:

    • Re-create the drill template images; they should print correctly from Firefox at least. Ship these as individual PDF files so they’re easy to print. @@ -2923,8 +2925,8 @@ individual PDF files so they’re easy to print. Add a description of the Apogee Lockout setting, which prevents the apogee charge from firing for a configurable amount of time after boost. -

F.17. Release Notes for Version 1.3.2

Version 1.3.2 is a minor release. It includes small bug fixes for -the TeleMega flight software and AltosUI ground station

F.17.1. AltOS

AltOS fixes:

  • +

F.18. Release Notes for Version 1.3.2

Version 1.3.2 is a minor release. It includes small bug fixes for +the TeleMega flight software and AltosUI ground station

F.18.1. AltOS

AltOS fixes:

  • On TeleMega, limit number of logged GPS status information to 12 satellites. That’s all there is room for in the log structure. @@ -2934,7 +2936,7 @@ position and keeps sending that if we lose GPS lock. Marks locked/unlocked by sending L/U in the APRS comment field along with the number of sats in view and voltages. -

F.17.2. AltosUI Application

AltosUI fixes:

  • +

F.18.2. AltosUI Application

AltosUI fixes:

  • If the TeleMega flight firmware reports that it has logged information about more than 12 satellites, don’t believe it as the log only holds 12 satellite @@ -2947,8 +2949,8 @@ data. Use letters (A, B, C, D) for alternate pyro channel names instead of numbers (0, 1, 2, 3) in the Fire Igniter dialog. -

F.18. Release Notes for Version 1.3.1

Version 1.3.1 is a minor release. It improves support for -TeleMega, TeleMetrum v2.0, TeleMini v2.0 and EasyMini.

F.18.1. AltOS

AltOS new features:

  • +

F.19. Release Notes for Version 1.3.1

Version 1.3.1 is a minor release. It improves support for +TeleMega, TeleMetrum v2.0, TeleMini v2.0 and EasyMini.

F.19.1. AltOS

AltOS new features:

  • Improved APRS mode. Now uses compressed position format for smaller data size, improved precision and to include altitude data as well as latitude and @@ -2970,7 +2972,7 @@ Fix antenna-down mode accelerometer configuration. Antenna down mode wasn’t working because the accelerometer calibration values were getting re-computed incorrectly in inverted mode. -

F.18.2. AltosUI Application

AltosUI new features:

  • +

F.19.2. AltosUI Application

AltosUI new features:

  • Display additional TeleMega sensor values in real units. Make all of these values available for plotting. Display TeleMega orientation value in the @@ -2984,8 +2986,8 @@ Main. Limit data rate when downloading satellite images from Google to make sure we stay within their limits so that all of the map tiles download successfully. -

F.19. Release Notes for Version 1.3

Version 1.3 is a major release. It adds support for TeleMega, -TeleMetrum v2.0, TeleMini v2.0 and EasyMini.

F.19.1. AltOS

AltOS new features:

  • +

F.20. Release Notes for Version 1.3

Version 1.3 is a major release. It adds support for TeleMega, +TeleMetrum v2.0, TeleMini v2.0 and EasyMini.

F.20.1. AltOS

AltOS new features:

  • Add STM32L processor support. This includes enhancements to the scheduler to support products with many threads. @@ -3009,7 +3011,7 @@ accelerometer, Invensense MPU6000 3-axis accelerometer + 3 axis gyro, Honeywell HMC5883 3-axis magnetic sensor and the TI CC1120 and CC115L digital FM transceivers -

F.19.2. AltosUI Application

AltosUI new features:

  • +

F.20.2. AltosUI Application

AltosUI new features:

  • Support TeleMega, TeleMetrum v2.0, TeleMini v2.0 and EasyMini telemetry and log formats.

AltosUI fixes:

  • @@ -3022,9 +3024,9 @@ Add Download button to menu bar.
  • Save the last log directory and offer that as the default for new downloads -

F.20. Release Notes for Version 1.2.1

Version 1.2.1 is a minor release. It adds support for TeleBT and +

F.21. Release Notes for Version 1.2.1

Version 1.2.1 is a minor release. It adds support for TeleBT and the AltosDroid application, provides several new features in -AltosUI and fixes some bugs in the AltOS firmware.

F.20.1. AltOS

AltOS new features:

  • +AltosUI and fixes some bugs in the AltOS firmware.

    F.21.1. AltOS

    AltOS new features:

    • Add support for TeleBT

    AltOS fixes:

    • In TeleMini recovery mode (when booted with the @@ -3044,7 +3046,7 @@ Adjusted the automatic gain control parameters that affect receive performance for TeleDongle. Field tests indicate that this may improve receive performance somewhat. -

    F.20.2. AltosUI Application

    AltosUI application new features:

    • +

    F.21.2. AltosUI Application

    AltosUI application new features:

    • Make the initial position of the AltosUI top level window configurable. Along with this change, the other windows will pop up at sensible places now, @@ -3078,15 +3080,15 @@ progress. Unfortunately, we don’t know how many blocks will need to be downloaded, but at least it isn’t just sitting there doing nothing for a long time. -

    F.20.3. AltosDroid

    • +

    F.21.3. AltosDroid

    • First version of this application -

F.21. Release Notes for Version 1.2

Version 1.2 is a major release. It adds support for MicroPeak -and the MicroPeak USB adapter.

F.21.1. AltOS

AltOS New Features:

  • +

F.22. Release Notes for Version 1.2

Version 1.2 is a major release. It adds support for MicroPeak +and the MicroPeak USB adapter.

F.22.1. AltOS

AltOS New Features:

  • Add MicroPeak support. This includes support for the ATtiny85 processor and adaptations to the core code to allow for devices too small to run the multi-tasking scheduler. -

F.21.2. AltosUI and MicroPeak Application

New Features:

  • +

F.22.2. AltosUI and MicroPeak Application

New Features:

  • Added MicroPeak application

AltosUI and MicroPeak fixes:

  • Distribute Mac OS X packages in disk image (.dmg) @@ -3097,11 +3099,11 @@ libraries to ensure that upgrades work properly, and to allow for multiple Altus Metrum software packages to be installed in the same directory at the same time. -

F.22. Release Notes for Version 1.1

Version 1.1.1 is a bug-fix release. It fixes a couple of bugs +

F.23. Release Notes for Version 1.1

Version 1.1.1 is a bug-fix release. It fixes a couple of bugs in AltosUI and one firmware bug that affects TeleMetrum version 1.0 boards. Thanks to Bob Brown for help diagnosing the Google Earth file export issue, and for suggesting the -addition of the Ground Distance value in the Descent tab.

F.22.1. AltOS

AltOS fixes:

  • +addition of the Ground Distance value in the Descent tab.

    F.23.1. AltOS

    AltOS fixes:

    • TeleMetrum v1.0 boards use the AT45DB081D flash memory part to store flight data, which is different from later TeleMetrum boards. The AltOS v1.1 driver @@ -3110,7 +3112,7 @@ impossible to delete flight data or update configuration values. This bug doesn’t affect newer TeleMetrum boards, and it doesn’t affect the safety of rockets flying version 1.1 firmware. -

    F.22.2. AltosUI

    AltosUI new features:

    • +

    F.23.2. AltosUI

    AltosUI new features:

    • The “Descent” tab displays the range to the rocket, which is a combination of the over-the-ground distance to the rockets current latitude/longitude @@ -3139,8 +3141,8 @@ things like battery voltage. The code that picked which kinds of data to fetch from the flight computer was missing a check for TeleMini when deciding whether to fetch the analog sensor data. -

F.23. Release Notes for Version 1.1

Version 1.1 is a minor release. It provides a few new features -in AltosUI and the AltOS firmware and fixes bugs.

F.23.1. AltOS

AltOS Firmware New Features:

  • +

F.24. Release Notes for Version 1.1

Version 1.1 is a minor release. It provides a few new features +in AltosUI and the AltOS firmware and fixes bugs.

F.24.1. AltOS

AltOS Firmware New Features:

  • Add apogee-lockout value. Overrides the apogee detection logic to prevent incorrect apogee charge firing. @@ -3160,7 +3162,7 @@ packets was from 320ms ago. Fix a bug which caused the old received telemetry packets to be retransmitted over the USB link when the radio was turned off and back on. -

F.23.2. AltosUI

AltosUI New Features:

  • +

F.24.2. AltosUI

AltosUI New Features:

  • Make the look-n-feel configurable, providing a choice from the available options.
  • @@ -3214,8 +3216,8 @@ the flight monitoring window. This eliminates entries duplicated from the header and adds both current altitude and pad altitude, which are useful in Monitor Idle mode. -

F.24. Release Notes for Version 1.0.1

Version 1.0.1 is a major release, adding support for the -TeleMini device and lots of new AltosUI features

F.24.1. AltOS

AltOS New Features

  • +

F.25. Release Notes for Version 1.0.1

Version 1.0.1 is a major release, adding support for the +TeleMini device and lots of new AltosUI features

F.25.1. AltOS

AltOS New Features

  • Add TeleMini v1.0 support.
  • Support operation of TeleMetrum with the antenna pointing @@ -3250,7 +3252,7 @@ within a fraction of a second. In addition, this approach allows the baro-only TeleMini device to correctly identify Mach transitions, avoiding the error-prone selection of a Mach delay. -

F.24.2. AltosUI Application

AltosUI New Features

  • +

F.25.2. AltosUI Application

AltosUI New Features

  • Add main/apogee voltage graphs to the data plot. This provides a visual indication if the igniters fail before being fired. @@ -3294,8 +3296,8 @@ waits indefinitely for the remote device to appear, providing a cancel button should the user get bored. This is necessary as the TeleMini can only be placed in "Idle" mode if AltosUI is polling it. -

F.25. Release Notes for Version 0.9.2

Version 0.9.2 is an AltosUI bug-fix release, with no firmware -changes.

F.25.1. AltosUI

AltosUI fixes:

  • +

F.26. Release Notes for Version 0.9.2

Version 0.9.2 is an AltosUI bug-fix release, with no firmware +changes.

F.26.1. AltosUI

AltosUI fixes:

  • Fix plotting problems due to missing file in the Mac OS install image.
  • @@ -3303,8 +3305,8 @@ Always read whole eeprom blocks, mark empty records invalid, display parsing errors to user.
  • Add software version to Configure AltosUI dialog -

F.26. Release Notes for Version 0.9

Version 0.9 adds a few new firmware features and accompanying -AltosUI changes, along with new hardware support.

F.26.1. AltOS

  • +

F.27. Release Notes for Version 0.9

Version 0.9 adds a few new firmware features and accompanying +AltosUI changes, along with new hardware support.

F.27.1. AltOS

  • Support for TeleMetrum v1.1 hardware. Sources for the flash memory part used in v1.0 dried up, so v1.1 uses a different part which required a new driver and support for explicit @@ -3321,12 +3323,12 @@ Previous versions used a telemetry packet format that provided only 8 bits for the device serial number. This change requires that both ends of the telemetry link be running the 0.9 firmware or they will not communicate. -

F.26.2. AltosUI Application

  • +

F.27.2. AltosUI Application

  • Support for telemetry format changes.
  • Support for multiple flight logs. -

F.27. Release Notes for Version 0.8

Version 0.8 offers a major upgrade in the AltosUI -interface.

F.27.1. AltosUI Application:

  • +

F.28. Release Notes for Version 0.8

Version 0.8 offers a major upgrade in the AltosUI +interface.

F.28.1. AltosUI Application:

  • Post-flight graphing tool. This lets you explore the behaviour of your rocket after flight with a scroll-able and zoom-able chart showing the altitude, speed and acceleration @@ -3365,8 +3367,8 @@ automatically connect to it and prepare to monitor a flight. Exports Google Earth flight tracks. Using the Keyhole Markup Language (.kml) file format, this provides a 3D view of your rocket flight through the Google Earth program. -

F.28. Release Notes for Version 0.7.1

Version 0.7.1 is the first release containing our new -cross-platform Java-based user interface.

F.28.1. AltosUI Application

  • +

F.29. Release Notes for Version 0.7.1

Version 0.7.1 is the first release containing our new +cross-platform Java-based user interface.

F.29.1. AltosUI Application

  • Receive and log telemetry from a connected TeleDongle device. All data received is saved to log files named with the current date and the connected rocket serial and flight diff --git a/AltOS/doc/altusmetrum.pdf b/AltOS/doc/altusmetrum.pdf index 3c05869..8ea8e48 100644 Binary files a/AltOS/doc/altusmetrum.pdf and b/AltOS/doc/altusmetrum.pdf differ diff --git a/AltOS/doc/companion.html b/AltOS/doc/companion.html index 7d90387..b9a684b 100644 --- a/AltOS/doc/companion.html +++ b/AltOS/doc/companion.html @@ -1,116 +1,79 @@ -AltOS Companion Port

    AltOS Companion Port

    Protocol Definitions

    Keith Packard

    Copyright © 2012 Keith Packard

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

    Revision History
    Revision 0.113 January 2012
    Initial content

    Table of Contents

    1. Companion Port
    2. Companion SPI Protocol
    3. SPI Message Formats
    3.1. Command Message
    3.2. SETUP reply message
    3.3. FETCH reply message
    4. History and Motivation

    1. Companion Port

    - Many Altus Metrum products come with an eight pin Micro MaTch - connector, called the Companion Port. This is often used to - program devices using a programming cable. However, it can also - be used to connect TeleMetrum to external companion boards - (hence the name). -

    - The Companion Port provides two different functions: -

    • - Power. Both battery-level and 3.3V regulated power are - available. Note that the amount of regulated power is not - huge; TeleMetrum contains a 150mA regulator and uses, at - peak, about 120mA or so. For applications needing more than - a few dozen mA, placing a separate regulator on them and - using the battery for power is probably a good idea. -

    • - SPI. The flight computer operates as a SPI master, using - a protocol defined in this document. Companion boards - provide a matching SPI slave implementation which supplies - telemetry information for the radio downlink during flight -

    -

    2. Companion SPI Protocol

    - The flight computer implements a SPI master communications - channel over the companion port, and uses this to get - information about a connected companion board and then to get - telemetry data for transmission during flight. -

    - At startup time, the flight computer sends a setup request - packet, and the companion board returns a board identifier, the - desired telemetry update period and the number of data channels - provided. The flight computer doesn't interpret the telemetry - data at all, simply packing it up and sending it over the link. - Telemetry packets are 32 bytes long, and companion packets use 8 - bytes as a header leaving room for a maximum of 12 16-bit data - values. -

    - Because of the limits of the AVR processors used in the first - two companion boards, the SPI data rate is set to 187.5kbaud. -

    3. SPI Message Formats

    - This section first defines the command message format sent from - the flight computer to the companion board, and then the various - reply message formats for each type of command message. -

    3.1. Command Message

    Table 1. Companion Command Message

    OffsetData TypeNameDescription
    0uint8_tcommandCommand identifier
    1uint8_tflight_stateCurrent flight computer state
    2uint16_ttickFlight computer clock (100 ticks/second)
    4uint16_tserialFlight computer serial number
    6uint16_tflightFlight number
    8   

    Table 2. Companion Command Identifiers

    ValueNameDescription
    1SETUPSupply the flight computer with companion - information
    2FETCHReturn telemetry information
    3NOTIFYTell companion board when flight state - changes

    - The flight computer will send a SETUP message shortly after - power-up and will then send FETCH messages no more often than - the rate specified in the SETUP reply. NOTIFY messages will be - sent whenever the flight state changes. -

    - 'flight_state' records the current state of the flight, - whether on the pad, under power, coasting to apogee or - descending on the drogue or main chute. -

    - 'tick' provides the current flight computer clock, which - be used to synchronize data recorded on the flight computer - with that recorded on the companion board in post-flight analysis. -

    - 'serial' is the product serial number of the flight computer, - 'flight' is the flight sequence number. Together, these two - uniquely identify the flight and can be recorded with any - companion board data logging to associate the companion data - with the proper flight. -

    - NOTIFY commands require no reply at all, they are used solely - to inform the companion board when the state of the flight, as - computed by the flight computer, changes. Companion boards can - use this to change data collection parameters, disabling data - logging until the flight starts and terminating it when the - flight ends. -

    3.2. SETUP reply message

    Table 3. SETUP reply contents

    OffsetData TypeNameDescription
    0uint16_tboard_idBoard identifier
    2uint16_tboard_id_inverse~board_id—used to tell if a board is present
    4uint8_tupdate_periodMinimum time (in 100Hz ticks) between FETCH commands
    5uint8_tchannelsNumber of data channels to retrieve in FETCH command
    6   

    - The SETUP reply contains enough information to uniquely - identify the companion board to the end user as well as for - the flight computer to know how many data values to expect in - reply to a FETCH command, and how often to fetch that data. -

    - To detect the presence of a companion board, the flight - computer checks to make sure that board_id_inverse is the - bit-wise inverse of board_id. Current companion boards use - USB product ID as the board_id, but the flight computer does - not interpret this data and so it can be any value. -

    3.3. FETCH reply message

    Table 4. FETCH reply contents

    OffsetData TypeNameDescription
    0uint16_tdata00th data item
    2uint16_tdata11st data item
    ...   

    - The FETCH reply contains arbitrary data to be reported over - the flight computer telemetry link. The number of 16-bit data items - must match the 'channels' value provided in the SETUP reply - message. -

    4. History and Motivation

    - To allow cross-programming, the original TeleMetrum and - TeleDongle designs needed to include some kind of - connector. With that in place, adding the ability to connect - external cards to TeleMetrum was fairly simple. We set the - software piece of this puzzle aside until we had a companion - board to use. -

    - The first companion board was TeleScience. Designed to collect - temperature data from the nose and fin of the airframe, the main - requirement for the companion port was that it be able to report - telemetry data during flight as a back-up in case the - TeleScience on-board data was lost. -

    - The second companion board, TelePyro, provides 8 additional - channels for deployment, staging or other activities. To avoid - re-programming the TeleMetrum to use TelePyro, we decided to - provide enough information over the companion link for it to - independently control those channels. -

    - Providing a standard, constant interface between the flight - computer and companion boards allows for the base flight - computer firmware to include support for companion boards. -

    + +AltOS Companion Port

    AltOS Companion Port

    Protocol Definitions

    Keith Packard

    Copyright © 2012 Keith Packard

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

    Table of Contents

    1. Companion Port
    2. Companion SPI Protocol
    3. SPI Message Formats
    3.1. SETUP reply message
    3.2. FETCH reply message
    4. History and Motivation

    1. Companion Port

    Many Altus Metrum products come with an eight pin Micro MaTch +connector, called the Companion Port. This is often used to +program devices using a programming cable. However, it can +also be used to connect TeleMetrum to external companion +boards (hence the name).

    The Companion Port provides two different functions:

    • +Power. Both battery-level and 3.3V regulated power are +available. Note that the amount of regulated power is not +huge; TeleMetrum contains a 150mA regulator and uses, at +peak, about 120mA or so. For applications needing more than +a few dozen mA, placing a separate regulator on them and +using the battery for power is probably a good idea. +
    • +SPI. The flight computer operates as a SPI master, using +a protocol defined in this document. Companion boards +provide a matching SPI slave implementation which supplies +telemetry information for the radio downlink during flight +

    2. Companion SPI Protocol

    The flight computer implements a SPI master communications +channel over the companion port, and uses this to get +information about a connected companion board and then to get +telemetry data for transmission during flight.

    At startup time, the flight computer sends a setup request +packet, and the companion board returns a board identifier, +the desired telemetry update period and the number of data +channels provided. The flight computer doesn’t interpret the +telemetry data at all, simply packing it up and sending it +over the link. Telemetry packets are 32 bytes long, and +companion packets use 8 bytes as a header leaving room for a +maximum of 12 16-bit data values.

    Because of the limits of the AVR processors used in the first +two companion boards, the SPI data rate is set to 187.5kbaud.

    3. SPI Message Formats

    This section first defines the command message format sent from +the flight computer to the companion board, and then the various +reply message formats for each type of command message.

    Table 1. Companion Command Message

    Offset

    Data Type

    Name

    Description

    0

    uint8_t

    command

    Command identifier

    1

    uint8_t

    flight_state

    Current flight computer state

    2

    uint16_t

    tick

    Flight computer clock (100 ticks/second)

    4

    uint16_t

    serial

    Flight computer serial number

    6

    uint16_t

    flight

    Flight number

    8


    Table 2. Companion Command Identifiers

    Value

    Name

    Description

    1

    SETUP

    Supply the flight computer with companion +information

    2

    FETCH

    Return telemetry information

    3

    NOTIFY

    Tell companion board when flight state changes


    The flight computer will send a SETUP message shortly after +power-up and will then send FETCH messages no more often than +the rate specified in the SETUP reply. NOTIFY messages will be +sent whenever the flight state changes.

    flight_state records the current state of the flight, +whether on the pad, under power, coasting to apogee or +descending on the drogue or main chute.

    tick provides the current flight computer clock, which +be used to synchronize data recorded on the flight computer +with that recorded on the companion board in post-flight analysis.

    serial is the product serial number of the flight computer, +flight is the flight sequence number. Together, these two +uniquely identify the flight and can be recorded with any +companion board data logging to associate the companion data +with the proper flight.

    NOTIFY commands require no reply at all, they are used solely +to inform the companion board when the state of the flight, as +computed by the flight computer, changes. Companion boards can +use this to change data collection parameters, disabling data +logging until the flight starts and terminating it when the +flight ends.

    3.1. SETUP reply message

    Table 3. SETUP reply contents

    Offset

    Data Type

    Name

    Description

    0

    uint16_t

    board_id

    Board identifier

    2

    uint16_t

    board_id_inverse

    ~board_id—used to tell if a board is present

    4

    uint8_t

    update_period

    Minimum time (in 100Hz ticks) between FETCH commands

    5

    uint8_t

    channels

    Number of data channels to retrieve in FETCH command

    6


    The SETUP reply contains enough information to uniquely +identify the companion board to the end user as well as for +the flight computer to know how many data values to expect in +reply to a FETCH command, and how often to fetch that data.

    To detect the presence of a companion board, the flight +computer checks to make sure that board_id_inverse is the +bit-wise inverse of board_id. Current companion boards use +USB product ID as the board_id, but the flight computer does +not interpret this data and so it can be any value.

    3.2. FETCH reply message

    Table 4. FETCH reply contents

    Offset

    Data Type

    Name

    Description

    0

    uint16_t

    data0

    0th data item

    2

    uint16_t

    data1

    1st data item

    …


    The FETCH reply contains arbitrary data to be reported +over the flight computer telemetry link. The number of +16-bit data items must match the channels value +provided in the SETUP reply message.

    4. History and Motivation

    To allow cross-programming, the original TeleMetrum and +TeleDongle designs needed to include some kind of +connector. With that in place, adding the ability to connect +external cards to TeleMetrum was fairly simple. We set the +software piece of this puzzle aside until we had a companion +board to use.

    The first companion board was TeleScience. Designed to collect +temperature data from the nose and fin of the airframe, the main +requirement for the companion port was that it be able to report +telemetry data during flight as a back-up in case the +TeleScience on-board data was lost.

    The second companion board, TelePyro, provides 8 additional +channels for deployment, staging or other activities. To avoid +re-programming the TeleMetrum to use TelePyro, we decided to +provide enough information over the companion link for it to +independently control those channels.

    Providing a standard, constant interface between the flight +computer and companion boards allows for the base flight +computer firmware to include support for companion boards.

    \ No newline at end of file diff --git a/AltOS/doc/companion.pdf b/AltOS/doc/companion.pdf index 3ef5655..2193112 100644 Binary files a/AltOS/doc/companion.pdf and b/AltOS/doc/companion.pdf differ diff --git a/AltOS/doc/easymega-outline.pdf b/AltOS/doc/easymega-outline.pdf index 4719261..e69de29 100644 Binary files a/AltOS/doc/easymega-outline.pdf and b/AltOS/doc/easymega-outline.pdf differ diff --git a/AltOS/doc/easymini-outline.pdf b/AltOS/doc/easymini-outline.pdf index 0771670..e69de29 100644 Binary files a/AltOS/doc/easymini-outline.pdf and b/AltOS/doc/easymini-outline.pdf differ diff --git a/AltOS/doc/easymini-revhistory.html b/AltOS/doc/easymini-revhistory.html index a91ec1f..b203a5e 100644 --- a/AltOS/doc/easymini-revhistory.html +++ b/AltOS/doc/easymini-revhistory.html @@ -1,5 +1,7 @@ -Revision History
    Revision History
    Revision 1.6.321 April 2016
    +Revision History
    Revision History
    Revision 1.8.420 Dec 2017
    + Support EasyMini v2.0 hardware. +
    Revision 1.6.321 April 2016
    Minor release fixing various host software bugs.
    Revision 1.6.210 January 2016
    First release of separate EasyMini doc diff --git a/AltOS/doc/easymini.html b/AltOS/doc/easymini.html index 82f5b44..03820f4 100644 --- a/AltOS/doc/easymini.html +++ b/AltOS/doc/easymini.html @@ -19,7 +19,7 @@ collaborators, and we certainly appreciate this level of contribution!

    Have fun using these products, and we hope to meet all of you out on the rocket flight line somewhere.

    Bdale Garbee, KB0G
    NAR #87103, TRA #12201

    Keith Packard, KD7SQG
    -NAR #88757, TRA #12200

    Table of Contents

    1. Introduction and Overview
    2. Getting Started
    2.1. Batteries
    2.2. Linux/Mac/Windows Ground Station Software
    3. Using Altus Metrum Hardware
    3.1. Wiring and Electrical Interference
    3.2. Hooking Up Lithium Polymer Batteries
    3.3. Hooking Up Pyro Charges
    3.4. Hooking Up a Power Switch
    3.5. Understanding Beeps
    3.6. Turning On the Power
    3.7. Using an External Active Switch Circuit
    3.8. Using a Separate Pyro Battery
    3.9. Using a Different Kind of Battery
    4. EasyMini
    4.1. EasyMini Screw Terminals
    4.2. Connecting A Battery To EasyMini
    4.3. Charging Lithium Batteries
    4.4. Using a Separate Pyro Battery with EasyMini
    4.5. Using an Active Switch with EasyMini
    5. Installation
    6. Using Altus Metrum Products
    6.1. In the Rocket
    6.2. On the Ground
    6.3. Data Analysis
    6.4. Future Plans
    7. AltosUI
    7.1. Save Flight Data
    7.2. Replay Flight
    7.3. Graph Data
    7.3.1. Flight Graph
    7.3.2. Configure Graph
    7.3.3. Flight Statistics
    7.4. Export Data
    7.4.1. Comma Separated Value Format
    7.5. Configure Altimeter
    7.5.1. Main Deploy Altitude
    7.5.2. Apogee Delay
    7.5.3. Apogee Lockout
    7.5.4. Maximum Flight Log Size
    7.5.5. Ignitor Firing Mode
    7.5.6. Beeper Frequency
    7.6. Configure AltosUI
    7.6.1. Log Directory
    7.6.2. Imperial Units
    7.6.3. Serial Debug
    7.6.4. Font size
    7.6.5. Look & feel
    7.6.6. Menu position
    7.7. Flash Image
    7.8. Fire Igniter
    A. System Operation
    A.1. Firmware Modes
    A.2. Ground Testing
    A.3. Configurable Parameters
    B. Handling Precautions
    C. Updating Device Firmware
    C.1. Updating EasyMini Firmware
    C.1.1. Recovering From Self-Flashing Failure
    D. Flight Data Recording
    E. Altus Metrum Hardware Specifications
    F. Release Notes
    F.1. Release Notes for Version 1.8.3
    F.1.1. AltOS
    F.1.2. AltosUI and TeleGPS Applications
    F.2. Release Notes for Version 1.8.2
    F.2.1. AltOS
    F.2.2. AltosUI and TeleGPS Applications
    F.3. Release Notes for Version 1.8.1
    F.3.1. AltOS
    F.3.2. AltosUI and TeleGPS Applications
    F.4. Release Notes for Version 1.8
    F.4.1. AltOS
    F.4.2. AltosUI and TeleGPS Applications
    F.5. Release Notes for Version 1.7
    F.5.1. AltOS
    F.5.2. AltosUI and TeleGPS Applications
    F.6. Release Notes for Version 1.6.8
    F.6.1. AltOS
    F.6.2. AltosUI, TeleGPS and AltosDroid Applications
    F.7. Release Notes for Version 1.6.5
    F.7.1. AltOS
    F.7.2. AltosUI, TeleGPS and AltosDroid Applications
    F.8. Release Notes for Version 1.6.4
    F.8.1. AltOS
    F.8.2. AltosUI, TeleGPS and AltosDroid Applications
    F.8.3. Documentation
    F.9. Release Notes for Version 1.6.3
    F.9.1. AltOS
    F.9.2. AltosUI and TeleGPS Applications
    F.9.3. AltosDroid
    F.9.4. Documentation
    F.10. Release Notes for Version 1.6.2
    F.10.1. AltOS
    F.10.2. AltosUI and TeleGPS Applications
    F.10.3. Documentation

    List of Figures

    4.1. EasyMini Board
    7.1. AltosUI Main Window
    7.2. Flight Data Graph
    7.3. Flight Graph Configuration
    7.4. Flight Statistics
    7.5. Altimeter Configuration
    7.6. Configure AltosUI Dialog
    7.7. Fire Igniter Window

    List of Tables

    3.1. AltOS Modes
    3.2. Pad/Idle Indications
    4.1. EasyMini Screw Terminals
    D.1. Data Storage on Altus Metrum altimeters
    E.1. Altus Metrum Flight Computer Electronics
    E.2. Altus Metrum Flight Computer Mechanical Components

    Chapter 1. Introduction and Overview

    Welcome to the Altus Metrum community! Our circuits and software reflect +NAR #88757, TRA #12200

    Table of Contents

    1. Introduction and Overview
    2. Getting Started
    2.1. Batteries
    2.2. Linux/Mac/Windows Ground Station Software
    3. Using Altus Metrum Hardware
    3.1. Wiring and Electrical Interference
    3.2. Hooking Up Lithium Polymer Batteries
    3.3. Hooking Up Pyro Charges
    3.4. Hooking Up a Power Switch
    3.5. Understanding Beeps
    3.6. Turning On the Power
    3.7. Using an External Active Switch Circuit
    3.8. Using a Separate Pyro Battery
    3.9. Using a Different Kind of Battery
    4. EasyMini
    4.1. EasyMini Screw Terminals
    4.2. Connecting A Battery To EasyMini
    4.3. Charging Lithium Batteries
    4.4. Using a Separate Pyro Battery with EasyMini
    4.5. Using an Active Switch with EasyMini
    5. Installation
    6. Using Altus Metrum Products
    6.1. In the Rocket
    6.2. On the Ground
    6.3. Data Analysis
    6.4. Future Plans
    7. AltosUI
    7.1. Save Flight Data
    7.2. Replay Flight
    7.3. Graph Data
    7.3.1. Flight Graph
    7.3.2. Configure Graph
    7.3.3. Flight Statistics
    7.4. Export Data
    7.4.1. Comma Separated Value Format
    7.5. Configure Altimeter
    7.5.1. Main Deploy Altitude
    7.5.2. Apogee Delay
    7.5.3. Apogee Lockout
    7.5.4. Maximum Flight Log Size
    7.5.5. Ignitor Firing Mode
    7.5.6. Beeper Frequency
    7.6. Configure AltosUI
    7.6.1. Log Directory
    7.6.2. Imperial Units
    7.6.3. Serial Debug
    7.6.4. Font size
    7.6.5. Look & feel
    7.6.6. Menu position
    7.7. Flash Image
    7.8. Fire Igniter
    A. System Operation
    A.1. Firmware Modes
    A.2. Ground Testing
    A.3. Configurable Parameters
    B. Handling Precautions
    C. Updating Device Firmware
    C.1. Updating EasyMini Firmware
    C.1.1. Recovering From Self-Flashing Failure
    D. Flight Data Recording
    E. Altus Metrum Hardware Specifications
    F. Release Notes
    F.1. Release Notes for Version 1.8.4
    F.1.1. AltOS
    F.2. Release Notes for Version 1.8.3
    F.2.1. AltOS
    F.2.2. AltosUI and TeleGPS Applications
    F.3. Release Notes for Version 1.8.2
    F.3.1. AltOS
    F.3.2. AltosUI and TeleGPS Applications
    F.4. Release Notes for Version 1.8.1
    F.4.1. AltOS
    F.4.2. AltosUI and TeleGPS Applications
    F.5. Release Notes for Version 1.8
    F.5.1. AltOS
    F.5.2. AltosUI and TeleGPS Applications
    F.6. Release Notes for Version 1.7
    F.6.1. AltOS
    F.6.2. AltosUI and TeleGPS Applications
    F.7. Release Notes for Version 1.6.8
    F.7.1. AltOS
    F.7.2. AltosUI, TeleGPS and AltosDroid Applications
    F.8. Release Notes for Version 1.6.5
    F.8.1. AltOS
    F.8.2. AltosUI, TeleGPS and AltosDroid Applications
    F.9. Release Notes for Version 1.6.4
    F.9.1. AltOS
    F.9.2. AltosUI, TeleGPS and AltosDroid Applications
    F.9.3. Documentation
    F.10. Release Notes for Version 1.6.3
    F.10.1. AltOS
    F.10.2. AltosUI and TeleGPS Applications
    F.10.3. AltosDroid
    F.10.4. Documentation
    F.11. Release Notes for Version 1.6.2
    F.11.1. AltOS
    F.11.2. AltosUI and TeleGPS Applications
    F.11.3. Documentation

    List of Figures

    4.1. EasyMini Board
    7.1. AltosUI Main Window
    7.2. Flight Data Graph
    7.3. Flight Graph Configuration
    7.4. Flight Statistics
    7.5. Altimeter Configuration
    7.6. Configure AltosUI Dialog
    7.7. Fire Igniter Window

    List of Tables

    3.1. AltOS Modes
    3.2. Pad/Idle Indications
    4.1. EasyMini Screw Terminals
    D.1. Data Storage on Altus Metrum altimeters
    E.1. Altus Metrum Flight Computer Electronics
    E.2. Altus Metrum Flight Computer Mechanical Components

    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 releasing all of our hardware and software designs under open licenses, @@ -105,12 +105,12 @@ beeping that accompanies each mode. In the description of the beeping pattern, “dit” means a short beep while "dah" means a long beep (three times as long). “Brap” means -a long dissonant tone.

    Table 3.1. AltOS Modes

    Mode Name

    Abbreviation

    Beeps

    Description

    Startup

    S

    battery voltage in decivolts

    Calibrating sensors, detecting orientation.

    Idle

    I

    dit dit

    Ready to accept commands over USB

    Pad

    P

    dit dah dah dit

    Waiting for launch. Not listening for commands.

    Boost

    B

    dah dit dit dit

    Accelerating upwards.

    Fast

    F

    dit dit dah dit

    Decelerating, but moving faster than 200m/s.

    Coast

    C

    dah dit dah dit

    Decelerating, moving slower than 200m/s

    Drogue

    D

    dah dit dit

    Descending after apogee. Above main height.

    Main

    M

    dah dah

    Descending. Below main height.

    Landed

    L

    dit dah dit dit

    Stable altitude for at least ten seconds.

    Sensor error

    X

    dah dit dit dah

    Error detected during sensor calibration.


    Here’s a summary of all of the Pad and Idle mode +a long dissonant tone.

    Table 3.1. AltOS Modes

    Mode Name

    Abbreviation

    Beeps

    Description

    Startup

    S

    battery voltage in decivolts

    Calibrating sensors, detecting orientation.

    Idle

    I

    dit dit

    Ready to accept commands over USB

    Pad

    P

    dit dah dah dit

    Waiting for launch. Not listening for commands.

    Boost

    B

    dah dit dit dit

    Accelerating upwards.

    Fast

    F

    dit dit dah dit

    Decelerating, but moving faster than 200m/s.

    Coast

    C

    dah dit dah dit

    Decelerating, moving slower than 200m/s

    Drogue

    D

    dah dit dit

    Descending after apogee. Above main height.

    Main

    M

    dah dah

    Descending. Below main height.

    Landed

    L

    dit dah dit dit

    Stable altitude for at least ten seconds.

    Sensor error

    X

    dah dit dit dah

    Error detected during sensor calibration.


    Here’s a summary of all of the Pad and Idle mode indications. In Idle mode, you’ll hear one of these just once after the two short dits indicating idle mode. In Pad mode, after the dit dah dah dit indicating Pad mode, you’ll hear these once every five -seconds.

    Table 3.2. Pad/Idle Indications

    Name Beeps Description

    Neither

    brap

    No continuity detected on either apogee or main igniters.

    Apogee

    dit

    Continuity detected only on apogee igniter.

    Main

    dit dit

    Continuity detected only on main igniter.

    Both

    dit dit dit

    Continuity detected on both igniters.

    Storage Full

    warble

    On-board data logging storage is full. This will +seconds.

    Table 3.2. Pad/Idle Indications

    Name Beeps Description

    Neither

    brap

    No continuity detected on either apogee or main igniters.

    Apogee

    dit

    Continuity detected only on apogee igniter.

    Main

    dit dit

    Continuity detected only on main igniter.

    Both

    dit dit dit

    Continuity detected on both igniters.

    Storage Full

    warble

    On-board data logging storage is full. This will not prevent the flight computer from safely controlling the flight or transmitting telemetry signals, but no record of the flight will be @@ -167,7 +167,7 @@ is designed to use either a lithium polymer battery or any other battery producing between 4 and 12 volts, such as a rectangular 9V -battery.

    Chapter 4. EasyMini

    Figure 4.1. EasyMini Board

    easymini-top.jpg

    EasyMini is built on a 0.8 inch by 1½ inch circuit board. It’s +battery.

    Chapter 4. EasyMini

    Figure 4.1. EasyMini Board

    easymini-top.jpg

    EasyMini is built on a 0.8 inch by 1½ inch circuit board. It’s designed to fit in a 24mm coupler tube.

    You usually don’t need to configure EasyMini at all; it’s set up to do dual-deployment with an event at apogee to separate the airframe and deploy a drogue and another event at 250m @@ -178,7 +178,7 @@ board. Using the picture above, the top four have connections for the main pyro circuit and an external battery and the bottom four have connections for the apogee pyro circuit and the power -switch. Counting from the left, the connections are as follows:

    Table 4.1. EasyMini Screw Terminals

    Terminal #Terminal NameDescription

    Top 1

    Main -

    Main pyro channel connection to pyro circuit

    Top 2

    Main

    Main pyro channel common connection to battery

    Top 3

    Battery

    Positive external battery terminal

    Top 4

    Battery -

    Negative external battery terminal

    Bottom 1

    Apogee -

    Apogee pyro channel connection to pyro circuit

    Bottom 2

    Apogee

    Apogee pyro channel common connection to battery

    Bottom 3

    Switch Output

    Switch connection to flight computer

    Bottom 4

    Switch Input

    Switch connection to positive battery terminal


    4.2. Connecting A Battery To EasyMini

    There are two possible battery connections on +switch. Counting from the left, the connections are as follows:

    Table 4.1. EasyMini Screw Terminals

    Terminal #Terminal NameDescription

    Top 1

    Main -

    Main pyro channel connection to pyro circuit

    Top 2

    Main

    Main pyro channel common connection to battery

    Top 3

    Battery

    Positive external battery terminal

    Top 4

    Battery -

    Negative external battery terminal

    Bottom 1

    Apogee -

    Apogee pyro channel connection to pyro circuit

    Bottom 2

    Apogee

    Apogee pyro channel common connection to battery

    Bottom 3

    Switch Output

    Switch connection to flight computer

    Bottom 4

    Switch Input

    Switch connection to positive battery terminal


    4.2. Connecting A Battery To EasyMini

    There are two possible battery connections on EasyMini. You can use either method; both feed through the power switch terminals.

    One battery connection is the standard Altus Metrum white JST plug. This mates with single-cell Lithium @@ -276,7 +276,7 @@ feel free to dive in and help! Or let us know what you’d like to see that we aren’t already working on, and maybe we’ll get excited about it too…

    Watch our web site for more news and information as our family of products -evolves!

    Chapter 7. AltosUI

    Figure 7.1. AltosUI Main Window

    altosui.png

    The AltosUI program provides a graphical user interface for +evolves!

    Chapter 7. AltosUI

    Figure 7.1. AltosUI Main Window

    altosui.png

    The AltosUI program provides a graphical user interface for interacting with the Altus Metrum product family. AltosUI can monitor telemetry data, configure devices and many other tasks. The primary interface window provides a selection of @@ -310,7 +310,7 @@ record file, either a .telem file recording telemetry data or a flash memory.

    Note that telemetry files will generally produce poor graphs due to the lower sampling rate and missed telemetry packets. Use saved flight data in .eeprom files for graphing where possible.

    Once a flight record is selected, a window with multiple tabs is -opened.

    7.3.1. Flight Graph

    Figure 7.2. Flight Data Graph

    graph.png

    By default, the graph contains acceleration (blue), +opened.

    7.3.1. Flight Graph

    Figure 7.2. Flight Data Graph

    graph.png

    By default, the graph contains acceleration (blue), velocity (green) and altitude (red).

    The graph can be zoomed into a particular area by clicking and dragging down and to the right. Once zoomed, the graph can be reset by clicking and @@ -318,7 +318,7 @@ dragging up and to the left. Holding down control and clicking and dragging allows the graph to be panned. The right mouse button causes a pop-up menu to be displayed, giving you the option save or print the -plot.

    7.3.2. Configure Graph

    Figure 7.3. Flight Graph Configuration

    graph-configure.png

    This selects which graph elements to show, and, at the +plot.

    7.3.2. Configure Graph

    Figure 7.3. Flight Graph Configuration

    graph-configure.png

    This selects which graph elements to show, and, at the very bottom. It also lets you configure how the graph is drawn:

    • Whether to use metric or imperial units @@ -339,7 +339,7 @@ descent. Flight computers without accelerometers always compute both speed and acceleration from barometric data. A larger value smooths the data more. -

    7.3.3. Flight Statistics

    Figure 7.4. Flight Statistics

    graph-stats.png

    Shows overall data computed from the flight.

    7.4. Export Data

    This tool takes the raw data files and makes them +

    7.3.3. Flight Statistics

    Figure 7.4. Flight Statistics

    graph-stats.png

    Shows overall data computed from the flight.

    7.4. 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, which can be either a .eeprom or .telem. The .eeprom @@ -358,7 +358,7 @@ tools can be configured to skip over.

    The remaining lines of the file cont each field separated by a comma and at least one space. All of the sensor values are converted to standard units, with the barometric data reported in -both pressure, altitude and height above pad units.

    7.5. Configure Altimeter

    Figure 7.5. Altimeter Configuration

    configure-altimeter.png

    Select this button and then select an altimeter.

    The first few lines of the dialog provide information about the +both pressure, altitude and height above pad units.

    7.5. Configure Altimeter

    Figure 7.5. Altimeter Configuration

    configure-altimeter.png

    Select this button and then select an altimeter.

    The first few lines of the dialog provide information about the connected device, including the product name, software version and hardware serial number. Below that are the individual configuration entries.

    At the bottom of the dialog, there are four buttons:

    @@ -442,7 +442,7 @@ have more than one flight computer in a single airframe, having all of them sound at the same frequency can be confusing. This parameter lets you adjust the base beeper frequency -value.

    7.6. Configure AltosUI

    Figure 7.6. Configure AltosUI Dialog

    configure-altosui.png

    This button presents a dialog so that you can +value.

    7.6. Configure AltosUI

    Figure 7.6. Configure AltosUI Dialog

    configure-altosui.png

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

    7.6.1. Log Directory

    AltosUI logs all telemetry data and saves all flash data to this directory. This directory is also used as the staring point @@ -476,7 +476,7 @@ EasyMini is programmed directly over USB (self programming). Please read the directions for flashing devices in -Appendix C, Updating Device Firmware.

    7.8. Fire Igniter

    Figure 7.7. Fire Igniter Window

    fire-igniter.png

    This activates the igniter circuits in the flight +Appendix C, Updating Device Firmware.

    7.8. Fire Igniter

    Figure 7.7. Fire Igniter Window

    fire-igniter.png

    This activates the igniter circuits in the flight computer to help test recovery systems deployment.

    Selecting the Fire Igniter button brings up the usual device selection dialog. Pick the desired @@ -642,7 +642,7 @@ during ascent and 10 samples per second during descent. Data are logged to an on-board flash memory part, which can be partitioned into -several equal-sized blocks, one for each flight.

    Table D.1. Data Storage on Altus Metrum altimeters

    Device Bytes per Sample Total Storage Minutes at Full Rate

    EasyMini

    16

    1MB

    10


    The on-board flash is partitioned into separate flight logs, +several equal-sized blocks, one for each flight.

    Table D.1. Data Storage on Altus Metrum altimeters

    Device Bytes per Sample Total Storage Minutes at Full Rate

    EasyMini

    16

    1MB

    10


    The on-board flash is partitioned into separate flight logs, each of a fixed maximum size. Increase the maximum size of each log and you reduce the number of flights that can be stored. Decrease the size and you can store more flights.

    Configuration data is also stored in the flash memory on @@ -661,11 +661,13 @@ flight data, so be sure to download flight data and erase it from the flight computer before it fills up. The flight computer will still successfully control the flight even if it cannot log data, so the only thing you will lose is the data.

    Appendix E. Altus Metrum Hardware Specifications

    Here’s the full set of Altus Metrum products, both in -production and retired.

    Table E.1. Altus Metrum Flight Computer Electronics

    Device Barometer Z-axis accel GPS 3D sensors Storage RF Output Battery

    EasyMini v1.0

    MS5607 30km (100k')

    -

    -

    -

    1MB

    -

    3.7-12V


    Table E.2. Altus Metrum Flight Computer Mechanical Components

    DeviceConnectorsScrew TerminalsWidthLengthTube Size

    EasyMini

    Debug USB Battery

    Apogee pyro Main pyro Battery

    0.8 inch (2.03cm)

    1½ inch (3.81cm)

    24mm coupler


    Appendix F. Release Notes

    F.1. Release Notes for Version 1.8.3

    Version 1.8.3 includes support for TeleMega version 3.0 along +production and retired.

    Table E.1. Altus Metrum Flight Computer Electronics

    Device Barometer Z-axis accel GPS 3D sensors Storage RF Output Battery

    EasyMini v1.0

    MS5607 30km (100k')

    -

    -

    -

    1MB

    -

    3.7-12V


    Table E.2. Altus Metrum Flight Computer Mechanical Components

    DeviceConnectorsScrew TerminalsWidthLengthTube Size

    EasyMini

    Debug USB Battery

    Apogee pyro Main pyro Battery

    0.8 inch (2.03cm)

    1½ inch (3.81cm)

    24mm coupler


    Appendix F. Release Notes

    F.1. Release Notes for Version 1.8.4

    Version 1.8.4 includes support for EasyMini version 2.0

    F.1.1. AltOS

    • +Support for EasyMini version 2.0 hardware. +

    F.2. Release Notes for Version 1.8.3

    Version 1.8.3 includes support for TeleMega version 3.0 along with two important flight computer fixes. This version also changes KML export data to make Tripoli Record reporting better and some updates to graph presentation and data -downloading.

    F.1.1. AltOS

    AltOS New Features

    • +downloading.

      F.2.1. AltOS

      AltOS New Features

      • Support for TeleMega version 3.0 hardware.

      AltOS Bug Fixes

      • Ground testing EasyMega and TeleMega additional pyro @@ -677,7 +679,7 @@ from capturing log data.
      • Fixed saving of pyro configuration that ended with Descending. -

      F.1.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • +

      F.2.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • Support for TeleMega version 3.0.
      • Graph lines have improved appearance to make them easier to @@ -701,18 +703,18 @@ to make it more useful for Tripoli record reporting.
      • CSV export now includes TeleMega/EasyMega pyro voltages and tilt angle. -

    F.2. Release Notes for Version 1.8.2

    Version 1.8.2 includes support for TeleGPS version 2.0 along +

    F.3. Release Notes for Version 1.8.2

    Version 1.8.2 includes support for TeleGPS version 2.0 along with accelerometer recalibration support in AltosUI.

    1.8.2 also contains a couple of minor fixes for AltosUI when -analyzing saved data files.

    F.2.1. AltOS

    AltOS New Features

    • +analyzing saved data files.

      F.3.1. AltOS

      AltOS New Features

      • Support for TeleGPS version 2.0 hardware. -

      F.2.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features

      • +

      F.3.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features

      • Support for TeleGPS version 2.0.
      • Accelerometer re-calibration user interface.

      AltosUI and TeleGPS Bug Fixes

      • Prevent some crashes when reading older saved flight data for graphing or KML export. -

    F.3. Release Notes for Version 1.8.1

    Version 1.8.1 includes an important bug fix for Apogee Lockout +

    F.4. Release Notes for Version 1.8.1

    Version 1.8.1 includes an important bug fix for Apogee Lockout operation in all flight computers. Anyone using this option must update firmware.

    This release also contains a change in how flight computers with accelerometers deal with speeds around and above Mach @@ -722,7 +724,7 @@ disregard the barometric sensor above 330m/s (around Mach effect without ever going away entirely. This prevents early drogue deployment for flights which spend considerable time above Mach 1.

    1.8.1 also contains a couple of minor fixes for AltosUI when -analyzing saved data files.

    F.3.1. AltOS

    AltOS Bug Fixes

    • +analyzing saved data files.

      F.4.1. AltOS

      AltOS Bug Fixes

      • Handle time value wrapping in Apogee Lockout correctly. Without this, apogee lockout would sometimes prevent any drogue charge from firing. @@ -731,7 +733,7 @@ Change Kalman filter on flight computers with accelerometer to continue using the barometric sensor even at high speeds to avoid unintentional drogue deployment during deceleration. -

      F.3.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • +

      F.4.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • Add new Huge font size to make text even bigger on high resolution monitors.

      AltosUI Bug Fixes

      • @@ -740,12 +742,12 @@ for graphing or KML export.
      • Load frequency preference at startup. The loading code was broken, so you’d see only the default frequencies. -

    F.4. Release Notes for Version 1.8

    Version 1.8 includes support for our new TeleBT v4.0 ground +

    F.5. Release Notes for Version 1.8

    Version 1.8 includes support for our new TeleBT v4.0 ground station, updates for data analysis in our ground station software and bug fixes in in the flight software for all our -boards and ground station interfaces.

    F.4.1. AltOS

    AltOS New Features

    • +boards and ground station interfaces.

      F.5.1. AltOS

      AltOS New Features

      • Add support for TeleBT v4.0 boards. -

      F.4.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • +

      F.5.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • Add support for TeleBT v4.0 hardware
      • Rewrite graphing and export functions. This code now handles @@ -756,20 +758,20 @@ acceleration data more accurate.

      AltosUI Bug Fixes

      • Correct axis labeling of magnetic sensor in TeleMega and EasyMega. The Y and Z axes were flipped. -

    F.5. Release Notes for Version 1.7

    Version 1.7 includes support for our new TeleMini v3.0 +

    F.6. Release Notes for Version 1.7

    Version 1.7 includes support for our new TeleMini v3.0 flight computer and bug fixes in in the flight software for all our boards -and ground station interfaces.

    F.5.1. AltOS

    AltOS New Features

    • +and ground station interfaces.

      F.6.1. AltOS

      AltOS New Features

      • Add support for TeleMini v3.0 boards.

      AltOS Fixes

      • Fix interrupt priorities on STM32L processors. Run timer interrupt at lowest priority so that device interrupts get serviced first. -

      F.5.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • +

      F.6.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • Add support for TeleMini v3.0 hardware -

    F.6. Release Notes for Version 1.6.8

    Version 1.6.8 fixes a TeleMega and TeleMetrum v2.0 bug where +

    F.7. Release Notes for Version 1.6.8

    Version 1.6.8 fixes a TeleMega and TeleMetrum v2.0 bug where the device could stop logging data and transmitting telemetry in flight. All TeleMega v1.0, v2.0 and TeleMetrum -v2.0 users should update their flight firmware.

    F.6.1. AltOS

    AltOS fixes:

    • +v2.0 users should update their flight firmware.

      F.7.1. AltOS

      AltOS fixes:

      • Fix STM32L DMA driver to work around STM32L SoC DMA priority issue t lock-up in the logging or radio code, either of which could stop data logging and telemetry. @@ -782,7 +784,7 @@ flight.

      AltOS changes:

      • Flash LEDS on all products briefly during power up so that they can be tested during production. -

      F.6.2. AltosUI, TeleGPS and AltosDroid Applications

      AltosUI fixes:

      • +

      F.7.2. AltosUI, TeleGPS and AltosDroid Applications

      AltosUI fixes:

      • Re-enable go/no-go entries after they’ve been disabled due to lack of data. If telemetry information is delayed when the Ui starts up, sometimes important fields would get @@ -790,20 +792,20 @@ disabled to never re-appear.
      • Deal with ground station failure better during Configure Ground Station operation by cleaning up pending operations. -

    F.7. Release Notes for Version 1.6.5

    Version 1.6.5 fixes a TeleMega and TeleMetrum v2.0 bug where +

    F.8. Release Notes for Version 1.6.5

    Version 1.6.5 fixes a TeleMega and TeleMetrum v2.0 bug where the device would often stop logging data and transmitting telemetry in flight. All TeleMega v1.0, v2.0 and TeleMetrum -v2.0 users should update their flight firmware.

    F.7.1. AltOS

    AltOS fixes:

    • +v2.0 users should update their flight firmware.

      F.8.1. AltOS

      AltOS fixes:

      • Fix STM32L SPI driver to prevent lock-up in the logging or radio code, either of which could stop data logging and telemetry. Found and characterized by Chuck Haskin, who also tested the new firmware before release. -

      F.7.2. AltosUI, TeleGPS and AltosDroid Applications

      AltosUI fixes:

      • +

      F.8.2. AltosUI, TeleGPS and AltosDroid Applications

      AltosUI fixes:

      • Deliver firmward for TeleMega v2.0 and TeleBT v3.0 with Windows package. -

    F.8. Release Notes for Version 1.6.4

    Version 1.6.4 fixes a bluetooth communication problem with +

    F.9. Release Notes for Version 1.6.4

    Version 1.6.4 fixes a bluetooth communication problem with TeleBT v1.0 devices, along with some altosui and altosdroid -minor nits. It also now ships firmware for some newer devices.

    F.8.1. AltOS

    AltOS fixes:

    • +minor nits. It also now ships firmware for some newer devices.

      F.9.1. AltOS

      AltOS fixes:

      • Fix hardware flow control on TeleBT v1.0. Hardware RTS/CTS doesn’t seem to work, switch from using the hardware to driving these pins with software. @@ -811,7 +813,7 @@ driving these pins with software. Fix ARM USB drivers to deal with OS restarts. Needed to reset all USB-related state when the USB bus is reset. These fixes affect all STM32L, STM32F0 and LPC11U14 based devices. -

      F.8.2. AltosUI, TeleGPS and AltosDroid Applications

      AltosUI, TeleGPS and AltosDroid New Features:

      • +

      F.9.2. AltosUI, TeleGPS and AltosDroid Applications

      AltosUI, TeleGPS and AltosDroid New Features:

      • Automatically switch from meters or feet to kilometers or miles for distance units.
      • @@ -822,17 +824,17 @@ Abort map preloading when the preload map dialog is closed. In AltosDroid, Don’t reconnect to last device if the user had disconnected it the last time the application was active. -

      F.8.3. Documentation

      • +

      F.9.3. Documentation

      • Mention TeleMega v2.0 in hardware specs table.
      • Document TeleGPS RF output in telegps manual. -

    F.9. Release Notes for Version 1.6.3

    Version 1.6.3 adds idle mode to AltosDroid and has bug fixes +

    F.10. Release Notes for Version 1.6.3

    Version 1.6.3 adds idle mode to AltosDroid and has bug fixes for our host software on desktops, laptops an android devices -along with BlueTooth support for Windows.

    F.9.1. AltOS

    AltOS fixes:

    • +along with BlueTooth support for Windows.

      F.10.1. AltOS

      AltOS fixes:

      • Fix hardware flow control on TeleBT v3.0. RTS/CTS is wired backwards on this board, switch from using the hardware to driving these pins with software. -

      F.9.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features:

      • +

      F.10.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features:

      • Add BlueTooth support for Windows operating system. This supports connections to TeleBT over BlueTooth rather than just USB. @@ -854,7 +856,7 @@ the connected Altus Metrum USB devices appear again.
      • Fix acceleration data presented in MonitorIdle mode for TeleMetrum v2.0 flight computers. -

      F.9.3. AltosDroid

      AltosDroid new features:

      • +

      F.10.3. AltosDroid

      AltosDroid new features:

      • Monitor Idle mode. Check state of flight computer while in idle mode over the radio link
      • @@ -892,12 +894,12 @@ Recover old tracker positions when restarting application. This finally allows you to safely stop and restart the application without losing the last known location of any tracker. -

      F.9.4. Documentation

      • +

      F.10.4. Documentation

      • Document TeleMega and EasyMega additional pyro channel continuity audio alert pattern. -

    F.10. Release Notes for Version 1.6.2

    Version 1.6.2 includes support for our updated TeleMega v2.0 +

    F.11. Release Notes for Version 1.6.2

    Version 1.6.2 includes support for our updated TeleMega v2.0 product and bug fixes in in the flight software for all our boards -and ground station interfaces.

    F.10.1. AltOS

    AltOS New Features:

    Table of Contents

    1. TeleGPS Quick Start Guide
    2. Using TeleGPS Hardware
    2.1. Hooking Up Lithium Polymer Batteries
    2.2. On-board Data Recording
    2.3. Installation
    3. TeleGPS Application
    3.1. Telemetry Monitoring
    3.1.1. Map
    3.1.2. Location
    3.1.3. Status
    3.1.4. Table
    3.2. TeleGPS Menus
    3.2.1. New Window
    3.3. Graph Data
    3.3.1. Data Graph
    3.3.2. Graph Configuration
    3.3.3. Statistics
    3.3.4. Map
    3.4. Export Data
    3.4.1. Comma Separated Value Format
    3.4.2. Keyhole Markup Language (for Google Earth)
    3.5. Load Maps
    3.6. Preferences
    3.6.1. Voice Settings
    3.6.2. Log Directory
    3.6.3. Callsign
    3.6.4. Imperial Units
    3.6.5. Serial Debug
    3.6.6. Font size
    3.6.7. Look & feel
    3.6.8. Menu position
    3.6.9. Map Cache Size
    3.6.10. Manage Frequencies
    3.7. Close
    3.8. Exit
    3.9. Connect Device
    3.10. Disconnect
    3.11. Scan Channels
    3.12. Download Data
    3.13. Configure Device
    3.13.1. Frequency
    3.13.2. RF Calibration
    3.13.3. Telemetry/RDF/APRS Enable
    3.13.4. Telemetry baud rate
    3.13.5. APRS Interval
    3.13.6. APRS SSID
    3.13.7. APRS Format
    3.13.8. Callsign
    3.13.9. Logging Trigger Motion
    3.13.10. Position Reporting Interval
    3.14. Flash Device
    A. TeleGPS System Operation
    A.1. GFSK Telemetry
    A.2. APRS
    A.3. Configurable Parameters
    B. Handling Precautions
    C. Technical Information
    C.1. GPS Receiver
    C.2. 70cm Transmitter
    C.3. Micro-controller
    C.4. Lithium Polymer Battery
    C.5. Mechanical Considerations
    C.6. On-board data storage
    D. Updating Device Firmware
    D.1. Updating TeleGPS Firmware
    E. Release Notes
    E.1. Release Notes for Version 1.8.4
    E.1.1. AltOS
    E.2. Release Notes for Version 1.8.3
    E.2.1. AltOS
    E.2.2. AltosUI and TeleGPS Applications
    E.3. Release Notes for Version 1.8.2
    E.3.1. AltOS
    E.3.2. AltosUI and TeleGPS Applications
    E.4. Release Notes for Version 1.8.1
    E.4.1. AltOS
    E.4.2. AltosUI and TeleGPS Applications
    E.5. Release Notes for Version 1.8
    E.5.1. AltOS
    E.5.2. AltosUI and TeleGPS Applications
    E.6. Release Notes for Version 1.7
    E.6.1. AltOS
    E.6.2. AltosUI and TeleGPS Applications
    E.7. Release Notes for Version 1.6.8
    E.7.1. AltOS
    E.7.2. AltosUI, TeleGPS and AltosDroid Applications
    E.8. Release Notes for Version 1.6.5
    E.8.1. AltOS
    E.8.2. AltosUI, TeleGPS and AltosDroid Applications
    E.9. Release Notes for Version 1.6.4
    E.9.1. AltOS
    E.9.2. AltosUI, TeleGPS and AltosDroid Applications
    E.9.3. Documentation
    E.10. Release Notes for Version 1.6.3
    E.10.1. AltOS
    E.10.2. AltosUI and TeleGPS Applications
    E.10.3. AltosDroid
    E.10.4. Documentation
    E.11. Release Notes for Version 1.6.2
    E.11.1. AltOS
    E.11.2. AltosUI and TeleGPS Applications
    E.11.3. Documentation
    E.12. Release Notes for Version 1.6.1
    E.12.1. AltOS
    E.12.2. AltosUI and TeleGPS Applications
    E.12.3. AltosDroid
    E.13. Release Notes for Version 1.6
    E.13.1. AltOS
    E.13.2. AltosUI and TeleGPS Applications
    E.14. Release Notes for Version 1.5
    E.14.1. AltOS
    E.14.2. AltosUI and TeleGPS Applications
    E.15. Release Notes for Version 1.4.2
    E.15.1. AltosUI and TeleGPS Applications
    E.16. Release Notes for Version 1.4.1
    E.16.1. AltosUI and TeleGPS Applications:
    E.17. Release Notes for Version 1.4
    E.17.1. AltOS
    E.17.2. AltosUI Application
    E.17.3. TeleGPS Application
    E.17.4. Documentation

    List of Figures

    3.1. TeleGPS Map View
    3.2. TeleGPS Location View
    3.3. TeleGPS Status View
    3.4. TeleGPS Information Table
    3.5. TeleGPS Graph
    3.6. TeleGPS Graph Configuration
    3.7. TeleGPS Statistics
    3.8. TeleGPS Map
    3.9. Load Maps Window
    3.10. TeleGPS Preferences Window
    3.11. Device Selection Dialog
    3.12. Radio Scanning Dialog
    3.13. TeleGPS Configuration Dialog

    List of Tables

    A.1. Altus Metrum APRS Comments

    Chapter 1. TeleGPS Quick Start Guide

    TeleGPS is designed to be easy to use. Requiring no external components, flying takes just a few steps.

    1. First, download and install the software from http://altusmetrum.org/AltOS. This will make sure that @@ -554,11 +554,13 @@ progress bar. Verify that the device is working by using the 'Configure Device item to check over the configuration. -

    Appendix E. Release Notes

    E.1. Release Notes for Version 1.8.3

    Version 1.8.3 includes support for TeleMega version 3.0 along +

    Appendix E. Release Notes

    E.1. Release Notes for Version 1.8.4

    Version 1.8.4 includes support for EasyMini version 2.0

    E.1.1. AltOS

    • +Support for EasyMini version 2.0 hardware. +

    E.2. Release Notes for Version 1.8.3

    Version 1.8.3 includes support for TeleMega version 3.0 along with two important flight computer fixes. This version also changes KML export data to make Tripoli Record reporting better and some updates to graph presentation and data -downloading.

    E.1.1. AltOS

    AltOS New Features

    • +downloading.

      E.2.1. AltOS

      AltOS New Features

      • Support for TeleMega version 3.0 hardware.

      AltOS Bug Fixes

      • Ground testing EasyMega and TeleMega additional pyro @@ -570,7 +572,7 @@ from capturing log data.
      • Fixed saving of pyro configuration that ended with Descending. -

      E.1.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • +

      E.2.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • Support for TeleMega version 3.0.
      • Graph lines have improved appearance to make them easier to @@ -594,18 +596,18 @@ to make it more useful for Tripoli record reporting.
      • CSV export now includes TeleMega/EasyMega pyro voltages and tilt angle. -

    E.2. Release Notes for Version 1.8.2

    Version 1.8.2 includes support for TeleGPS version 2.0 along +

    E.3. Release Notes for Version 1.8.2

    Version 1.8.2 includes support for TeleGPS version 2.0 along with accelerometer recalibration support in AltosUI.

    1.8.2 also contains a couple of minor fixes for AltosUI when -analyzing saved data files.

    E.2.1. AltOS

    AltOS New Features

    • +analyzing saved data files.

      E.3.1. AltOS

      AltOS New Features

      • Support for TeleGPS version 2.0 hardware. -

      E.2.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features

      • +

      E.3.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features

      • Support for TeleGPS version 2.0.
      • Accelerometer re-calibration user interface.

      AltosUI and TeleGPS Bug Fixes

      • Prevent some crashes when reading older saved flight data for graphing or KML export. -

    E.3. Release Notes for Version 1.8.1

    Version 1.8.1 includes an important bug fix for Apogee Lockout +

    E.4. Release Notes for Version 1.8.1

    Version 1.8.1 includes an important bug fix for Apogee Lockout operation in all flight computers. Anyone using this option must update firmware.

    This release also contains a change in how flight computers with accelerometers deal with speeds around and above Mach @@ -615,7 +617,7 @@ disregard the barometric sensor above 330m/s (around Mach effect without ever going away entirely. This prevents early drogue deployment for flights which spend considerable time above Mach 1.

    1.8.1 also contains a couple of minor fixes for AltosUI when -analyzing saved data files.

    E.3.1. AltOS

    AltOS Bug Fixes

    • +analyzing saved data files.

      E.4.1. AltOS

      AltOS Bug Fixes

      • Handle time value wrapping in Apogee Lockout correctly. Without this, apogee lockout would sometimes prevent any drogue charge from firing. @@ -624,7 +626,7 @@ Change Kalman filter on flight computers with accelerometer to continue using the barometric sensor even at high speeds to avoid unintentional drogue deployment during deceleration. -

      E.3.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • +

      E.4.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • Add new Huge font size to make text even bigger on high resolution monitors.

      AltosUI Bug Fixes

      • @@ -633,12 +635,12 @@ for graphing or KML export.
      • Load frequency preference at startup. The loading code was broken, so you’d see only the default frequencies. -

    E.4. Release Notes for Version 1.8

    Version 1.8 includes support for our new TeleBT v4.0 ground +

    E.5. Release Notes for Version 1.8

    Version 1.8 includes support for our new TeleBT v4.0 ground station, updates for data analysis in our ground station software and bug fixes in in the flight software for all our -boards and ground station interfaces.

    E.4.1. AltOS

    AltOS New Features

    • +boards and ground station interfaces.

      E.5.1. AltOS

      AltOS New Features

      • Add support for TeleBT v4.0 boards. -

      E.4.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • +

      E.5.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • Add support for TeleBT v4.0 hardware
      • Rewrite graphing and export functions. This code now handles @@ -649,20 +651,20 @@ acceleration data more accurate.

      AltosUI Bug Fixes

      • Correct axis labeling of magnetic sensor in TeleMega and EasyMega. The Y and Z axes were flipped. -

    E.5. Release Notes for Version 1.7

    Version 1.7 includes support for our new TeleMini v3.0 +

    E.6. Release Notes for Version 1.7

    Version 1.7 includes support for our new TeleMini v3.0 flight computer and bug fixes in in the flight software for all our boards -and ground station interfaces.

    E.5.1. AltOS

    AltOS New Features

    • +and ground station interfaces.

      E.6.1. AltOS

      AltOS New Features

      • Add support for TeleMini v3.0 boards.

      AltOS Fixes

      • Fix interrupt priorities on STM32L processors. Run timer interrupt at lowest priority so that device interrupts get serviced first. -

      E.5.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • +

      E.6.2. AltosUI and TeleGPS Applications

      AltosUI New Features

      • Add support for TeleMini v3.0 hardware -

    E.6. Release Notes for Version 1.6.8

    Version 1.6.8 fixes a TeleMega and TeleMetrum v2.0 bug where +

    E.7. Release Notes for Version 1.6.8

    Version 1.6.8 fixes a TeleMega and TeleMetrum v2.0 bug where the device could stop logging data and transmitting telemetry in flight. All TeleMega v1.0, v2.0 and TeleMetrum -v2.0 users should update their flight firmware.

    E.6.1. AltOS

    AltOS fixes:

    • +v2.0 users should update their flight firmware.

      E.7.1. AltOS

      AltOS fixes:

      • Fix STM32L DMA driver to work around STM32L SoC DMA priority issue t lock-up in the logging or radio code, either of which could stop data logging and telemetry. @@ -675,7 +677,7 @@ flight.

      AltOS changes:

      • Flash LEDS on all products briefly during power up so that they can be tested during production. -

      E.6.2. AltosUI, TeleGPS and AltosDroid Applications

      AltosUI fixes:

      • +

      E.7.2. AltosUI, TeleGPS and AltosDroid Applications

      AltosUI fixes:

      • Re-enable go/no-go entries after they’ve been disabled due to lack of data. If telemetry information is delayed when the Ui starts up, sometimes important fields would get @@ -683,20 +685,20 @@ disabled to never re-appear.
      • Deal with ground station failure better during Configure Ground Station operation by cleaning up pending operations. -

    E.7. Release Notes for Version 1.6.5

    Version 1.6.5 fixes a TeleMega and TeleMetrum v2.0 bug where +

    E.8. Release Notes for Version 1.6.5

    Version 1.6.5 fixes a TeleMega and TeleMetrum v2.0 bug where the device would often stop logging data and transmitting telemetry in flight. All TeleMega v1.0, v2.0 and TeleMetrum -v2.0 users should update their flight firmware.

    E.7.1. AltOS

    AltOS fixes:

    • +v2.0 users should update their flight firmware.

      E.8.1. AltOS

      AltOS fixes:

      • Fix STM32L SPI driver to prevent lock-up in the logging or radio code, either of which could stop data logging and telemetry. Found and characterized by Chuck Haskin, who also tested the new firmware before release. -

      E.7.2. AltosUI, TeleGPS and AltosDroid Applications

      AltosUI fixes:

      • +

      E.8.2. AltosUI, TeleGPS and AltosDroid Applications

      AltosUI fixes:

      • Deliver firmward for TeleMega v2.0 and TeleBT v3.0 with Windows package. -

    E.8. Release Notes for Version 1.6.4

    Version 1.6.4 fixes a bluetooth communication problem with +

    E.9. Release Notes for Version 1.6.4

    Version 1.6.4 fixes a bluetooth communication problem with TeleBT v1.0 devices, along with some altosui and altosdroid -minor nits. It also now ships firmware for some newer devices.

    E.8.1. AltOS

    AltOS fixes:

    • +minor nits. It also now ships firmware for some newer devices.

      E.9.1. AltOS

      AltOS fixes:

      • Fix hardware flow control on TeleBT v1.0. Hardware RTS/CTS doesn’t seem to work, switch from using the hardware to driving these pins with software. @@ -704,7 +706,7 @@ driving these pins with software. Fix ARM USB drivers to deal with OS restarts. Needed to reset all USB-related state when the USB bus is reset. These fixes affect all STM32L, STM32F0 and LPC11U14 based devices. -

      E.8.2. AltosUI, TeleGPS and AltosDroid Applications

      AltosUI, TeleGPS and AltosDroid New Features:

      • +

      E.9.2. AltosUI, TeleGPS and AltosDroid Applications

      AltosUI, TeleGPS and AltosDroid New Features:

      • Automatically switch from meters or feet to kilometers or miles for distance units.
      • @@ -715,17 +717,17 @@ Abort map preloading when the preload map dialog is closed. In AltosDroid, Don’t reconnect to last device if the user had disconnected it the last time the application was active. -

      E.8.3. Documentation

      • +

      E.9.3. Documentation

      • Mention TeleMega v2.0 in hardware specs table.
      • Document TeleGPS RF output in telegps manual. -

    E.9. Release Notes for Version 1.6.3

    Version 1.6.3 adds idle mode to AltosDroid and has bug fixes +

    E.10. Release Notes for Version 1.6.3

    Version 1.6.3 adds idle mode to AltosDroid and has bug fixes for our host software on desktops, laptops an android devices -along with BlueTooth support for Windows.

    E.9.1. AltOS

    AltOS fixes:

    • +along with BlueTooth support for Windows.

      E.10.1. AltOS

      AltOS fixes:

      • Fix hardware flow control on TeleBT v3.0. RTS/CTS is wired backwards on this board, switch from using the hardware to driving these pins with software. -

      E.9.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features:

      • +

      E.10.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features:

      • Add BlueTooth support for Windows operating system. This supports connections to TeleBT over BlueTooth rather than just USB. @@ -747,7 +749,7 @@ the connected Altus Metrum USB devices appear again.
      • Fix acceleration data presented in MonitorIdle mode for TeleMetrum v2.0 flight computers. -

      E.9.3. AltosDroid

      AltosDroid new features:

      • +

      E.10.3. AltosDroid

      AltosDroid new features:

      • Monitor Idle mode. Check state of flight computer while in idle mode over the radio link
      • @@ -785,12 +787,12 @@ Recover old tracker positions when restarting application. This finally allows you to safely stop and restart the application without losing the last known location of any tracker. -

      E.9.4. Documentation

      • +

      E.10.4. Documentation

      • Document TeleMega and EasyMega additional pyro channel continuity audio alert pattern. -

    E.10. Release Notes for Version 1.6.2

    Version 1.6.2 includes support for our updated TeleMega v2.0 +

    E.11. Release Notes for Version 1.6.2

    Version 1.6.2 includes support for our updated TeleMega v2.0 product and bug fixes in in the flight software for all our boards -and ground station interfaces.

    E.10.1. AltOS

    AltOS New Features:

    • +and ground station interfaces.

      E.11.1. AltOS

      AltOS New Features:

      • Add support for TeleMega v2.0 boards.
      • Add PWM servo driver. There’s no higher level code using @@ -799,14 +801,14 @@ servo output connector.

      AltOS Fixes:

      • Slow down telemetry packets to allow receiver to keep up. -

      E.10.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS Fixes:

      • +

      E.11.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS Fixes:

      • Fix post-flight orientation computation when processing TeleMega and EasyMega eeprom data files.
      • Capture complete eeprom data even when there are invalid entries in the data. This keeps reading eeprom contents and writing the associated .eeprom file when an error is detected. -

      E.10.3. Documentation

      We spent a bunch of time trying to improve our documentation

      • +

      E.11.3. Documentation

      We spent a bunch of time trying to improve our documentation

      • HTML versions now have a table of contents on the left side.
      • EasyMini now has its own shorter manual. @@ -815,9 +817,9 @@ Provide links between sections in each document.
      • Lots of minor rewriting and restructuring to avoid duplication of information -

    E.11. Release Notes for Version 1.6.1

    Version 1.6.1 includes support for our updated TeleBT v3.0 +

    E.12. Release Notes for Version 1.6.1

    Version 1.6.1 includes support for our updated TeleBT v3.0 product and bug fixes in in the flight software for all our boards -and ground station interfaces.

    E.11.1. AltOS

    AltOS New Features:

    • +and ground station interfaces.

      E.12.1. AltOS

      AltOS New Features:

      • Add support for TeleBT v3.0 boards.
      • Add support for uncompressed APRS data, providing support @@ -827,7 +829,7 @@ altitude data.

      AltOS Fixes:

      • Make TeleDongle and TeleBT more tolerant of data rate variations from transmitting devices. -

      E.11.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features:

      • +

      E.12.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features:

      • Add map to Monitor Idle display. It’s nice to be able to verify that maps are working, instead of needing to use Monitor Flight. @@ -865,7 +867,7 @@ will take longer to respond to changes now.
      • Make Replay Flight run in realtime again. It had been set to run at 10x speed by mistake. -

      E.11.3. AltosDroid

      AltosDroid New Features:

      • +

      E.12.3. AltosDroid

      AltosDroid New Features:

      • Add offline map support using mapping code from AltosUI.
      • Support TeleDongle (and TeleBT via USB) on devices @@ -893,9 +895,9 @@ Make voice announcements depend on current tab.
      • Compute adjustment to current travel direction while in motion towards rocket. -

    E.12. Release Notes for Version 1.6

    Version 1.6 includes support for our updated TeleDongle v3.0 +

    E.13. Release Notes for Version 1.6

    Version 1.6 includes support for our updated TeleDongle v3.0 product and bug fixes in in the flight software for all our boards -and ground station interfaces.

    E.12.1. AltOS

    AltOS New Features

    • +and ground station interfaces.

      E.13.1. AltOS

      AltOS New Features

      • Add support for TeleDongle v3.0 boards.

      AltOS Fixes

      • Don’t beep out the continuity twice by accident in idle mode. @@ -915,7 +917,7 @@ interrupt code would occasionally wedge on long transfers if interrupts were blocked for too long. This affects all released TeleGPS products; if you have a TeleGPS device, you’ll want to reflash the firmware. -

      E.12.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features

      • +

      E.13.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features

      • Compute tilt angle from TeleMega and EasyMega log files. This duplicates the quaternion-based angle tracking code from the flight firmware inside the ground station @@ -961,9 +963,9 @@ five seconds these days. In the Scan Channels code, reset pending flight state information each time we change channels. This avoids having flight computers appear on multiple frequencies by accident. -

    E.13. Release Notes for Version 1.5

    Version 1.5 is a major release. It includes support for our new +

    E.14. Release Notes for Version 1.5

    Version 1.5 is a major release. It includes support for our new EasyMega product, new features and bug fixes in in the flight -software for all our boards and the AltosUI ground station

    E.13.1. AltOS

    AltOS New Features

    • +software for all our boards and the AltosUI ground station

      E.14.1. AltOS

      AltOS New Features

      • Add support for EasyMega boards.
      • Make the APRS SSID be configurable. This lets you track @@ -997,7 +999,7 @@ the delay, but become bad before the delay expires. Allow negative numbers in pyro configuration values. This lets you specify things like descending speed or deceleration. -

      E.13.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features

      • +

      E.14.2. AltosUI and TeleGPS Applications

      AltosUI and TeleGPS New Features

      • Support telemetry baud rate selection. Adds menus to the flight monitoring and configuration for baud rate selection. @@ -1014,18 +1016,18 @@ Make the Graph button on the landed tab w Make tests for Java on Windows a bit smarter, and also provide the user with the option to skip installing Java for cases where we just can’t figure out what version is installed. -

    E.14. Release Notes for Version 1.4.2

    Version 1.4.2 is a minor release. It fixes Java-related install issues on -Windows

    E.14.1. AltosUI and TeleGPS Applications

    Windows Install Fixes

    • +

    E.15. Release Notes for Version 1.4.2

    Version 1.4.2 is a minor release. It fixes Java-related install issues on +Windows

    E.15.1. AltosUI and TeleGPS Applications

    Windows Install Fixes

    • Checks for Java installation data in more registry locations.
    • Allows user to bypass Java installation in case the detection fails. -

    E.15. Release Notes for Version 1.4.1

    Version 1.4.1 is a minor release. It fixes install issues on +

    E.16. Release Notes for Version 1.4.1

    Version 1.4.1 is a minor release. It fixes install issues on Windows and provides the missing TeleMetrum V2.0 firmware. There aren’t any changes to the firmware or host applications at all. All Windows users will want to upgrade to get the signed driver, but Mac and Linux users who do not need the TeleMetrum -V2.0 firmware image will not need to upgrade.

    E.15.1. AltosUI and TeleGPS Applications:

    Windows Install Fixes

    • +V2.0 firmware image will not need to upgrade.

      E.16.1. AltosUI and TeleGPS Applications:

      Windows Install Fixes

      • Provide signed Windows driver files. This should avoid any need to disable driver signature checking on Windows 7 or 8.
      • @@ -1043,9 +1045,9 @@ packages for Linux, Mac and Windows. Include Google Application Key for map downloading. The 1.4 release didn’t have this key in the released version of the software, making map downloading fail for most people. -

    E.16. Release Notes for Version 1.4

    Version 1.4 is a major release. It includes support for our new +

    E.17. Release Notes for Version 1.4

    Version 1.4 is a major release. It includes support for our new TeleGPS product, new features and bug fixes in in the flight -software for all our boards and the AltosUI ground station

    E.16.1. AltOS

    AltOS new features:

    • +software for all our boards and the AltosUI ground station

      E.17.1. AltOS

      AltOS new features:

      • Add support for TeleGPS boards.
      • Make the beeper tone configurable, making it @@ -1075,7 +1077,7 @@ number to 2 on TeleMega and TeleMetrum v2.
      • Fix u-Blox GPS driver to mark course and speed data as being present. -

      E.16.2. AltosUI Application

      AltosUI new features:

      • +

      E.17.2. AltosUI Application

      AltosUI new features:

      • Add zooming and new content types (terrain and road maps) to map view. Change map storage format from PNG to Jpeg, which saves a huge amount of disk @@ -1132,12 +1134,12 @@ Handle TeleMetrum and TeleMini eeprom files generated with pre-1.0 firmware. Those ancient versions didn’t report the log format, so just use the product name instead. -

      E.16.3. TeleGPS Application

      • +

      E.17.3. TeleGPS Application

      • New application designed for use with TeleGPS boards.
      • Shares code with AltosUI, mostly just trimmed down to focus on TeleGPS-related functions. -

      E.16.4. Documentation

      Documentation changes:

      • +

      E.17.4. Documentation

      Documentation changes:

      • Re-create the drill template images; they should print correctly from Firefox at least. Ship these as individual PDF files so they’re easy to print. diff --git a/AltOS/doc/telegps.pdf b/AltOS/doc/telegps.pdf index 9b3c2eb..29134c3 100644 Binary files a/AltOS/doc/telegps.pdf and b/AltOS/doc/telegps.pdf differ diff --git a/AltOS/doc/telemega-outline.pdf b/AltOS/doc/telemega-outline.pdf index 043836f..e69de29 100644 Binary files a/AltOS/doc/telemega-outline.pdf and b/AltOS/doc/telemega-outline.pdf differ diff --git a/AltOS/doc/telemetrum-outline.pdf b/AltOS/doc/telemetrum-outline.pdf index 82ae9b4..e69de29 100644 Binary files a/AltOS/doc/telemetrum-outline.pdf and b/AltOS/doc/telemetrum-outline.pdf differ diff --git a/AltOS/doc/telemetry.html b/AltOS/doc/telemetry.html index 5113c2a..ac37b9f 100644 --- a/AltOS/doc/telemetry.html +++ b/AltOS/doc/telemetry.html @@ -1,200 +1,133 @@ -AltOS Telemetry

        AltOS Telemetry

        Packet Definitions

        Keith Packard

        Copyright © 2011 Keith Packard

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

        Revision History
        Revision 0.101 July 2011
        Initial content

        Table of Contents

        1. Packet Format Design
        2. Packet Formats
        2.1. Packet Header
        2.2. TeleMetrum v1.x, TeleMini and TeleNano Sensor Data
        2.3. TeleMega Sensor Data
        2.4. TeleMetrum v2 Sensor Data
        2.5. Configuration Data
        2.6. GPS Location
        2.7. GPS Satellite Data
        2.8. Companion Data Data
        3. Data Transmission
        3.1. Modulation Scheme
        3.2. Error Correction
        4. TeleDongle packet format
        5. History and Motivation

        1. Packet Format Design

        - AltOS telemetry data is split into multiple different packets, - all the same size, but each includs an identifier so that the - ground station can distinguish among different types. A single - flight board will transmit multiple packet types, each type on a - different schedule. The ground software need look for only a - single packet size, and then decode the information within the - packet and merge data from multiple packets to construct the - full flight computer state. -

        - Each AltOS packet is 32 bytes long. This size was chosen based - on the known telemetry data requirements. The power of two size - allows them to be stored easily in flash memory without having - them split across blocks or leaving gaps at the end. -

        - All packet types start with a five byte header which encodes the - device serial number, device clock value and the packet - type. The remaining 27 bytes encode type-specific data. -

        2. Packet Formats

        - This section first defines the packet header common to all packets - and then the per-packet data layout. -

        2.1. Packet Header

        Table 1. Telemetry Packet Header

        OffsetData TypeNameDescription
        0uint16_tserialDevice serial Number
        2uint16_ttickDevice time in 100ths of a second
        4uint8_ttypePacket type
        5   

        - Each packet starts with these five bytes which serve to identify - which device has transmitted the packet, when it was transmitted - and what the rest of the packet contains. -

        2.2. TeleMetrum v1.x, TeleMini and TeleNano Sensor Data

        TypeDescription
        0x01TeleMetrum v1.x Sensor Data
        0x02TeleMini Sensor Data
        0x03TeleNano Sensor Data

        - TeleMetrum v1.x, TeleMini and TeleNano share this same packet - format for sensor data. Each uses a distinct packet type so - that the receiver knows which data values are valid and which - are undefined. -

        - Sensor Data packets are transmitted once per second on the - ground, 10 times per second during ascent and once per second - during descent and landing -

        Table 2. Sensor Packet Contents

        OffsetData TypeNameDescription
        5uint8_tstateFlight state
        6int16_taccelaccelerometer (TM only)
        8int16_tprespressure sensor
        10int16_ttemptemperature sensor
        12int16_tv_battbattery voltage
        14int16_tsense_ddrogue continuity sense (TM/Tm)
        16int16_tsense_mmain continuity sense (TM/Tm)
        18int16_taccelerationm/s² * 16
        20int16_tspeedm/s * 16
        22int16_theightm
        24int16_tground_presAverage barometer reading on ground
        26int16_tground_accelTM
        28int16_taccel_plus_gTM
        30int16_taccel_minus_gTM
        32   

        2.3. TeleMega Sensor Data

        TypeDescription
        0x08TeleMega IMU Sensor Data
        0x09TeleMega Kalman and Voltage Data

        - TeleMega has a lot of sensors, and so it splits the sensor - data into two packets. The raw IMU data are sent more often; - the voltage values don't change very fast, and the Kalman - values can be reconstructed from the IMU data. -

        - IMU Sensor Data packets are transmitted once per second on the - ground, 10 times per second during ascent and once per second - during descent and landing -

        - Kalman and Voltage Data packets are transmitted once per second on the - ground, 5 times per second during ascent and once per second - during descent and landing -

        - The high-g accelerometer is reported separately from the data - for the 9-axis IMU (accel/gyro/mag). The 9-axis IMU is mounted - so that the X axis is "across" the board (along the short - axis0, the Y axis is "along" the board (along the long axis, - with the high-g accelerometer) and the Z axis is "through" the - board (perpendicular to the board). Rotation measurements are - around the respective axis, so Y rotation measures the spin - rate of the rocket while X and Z rotation measure the tilt - rate. -

        - The overall tilt angle of the rocket is computed by first - measuring the orientation of the rocket on the pad using the 3 - axis accelerometer, and then integrating the overall tilt rate - from the 3 axis gyroscope to compute the total orientation - change of the airframe since liftoff. -

        Table 3. TeleMega IMU Sensor Packet Contents

        OffsetData TypeNameDescription
        5uint8_torientAngle from vertical in degrees
        6int16_taccelHigh G accelerometer
        8int32_tprespressure (Pa * 10)
        12int16_ttemptemperature (°C * 100)
        14int16_taccel_xX axis acceleration (across)
        16int16_taccel_yY axis acceleration (along)
        18int16_taccel_zZ axis acceleration (through)
        20int16_tgyro_xX axis rotation (across)
        22int16_tgyro_yY axis rotation (along)
        24int16_tgyro_zZ axis rotation (through)
        26int16_tmag_xX field strength (across)
        28int16_tmag_yY field strength (along)
        30int16_tmag_zZ field strength (through)
        32   

        Table 4. TeleMega Kalman and Voltage Data Packet Contents

        OffsetData TypeNameDescription
        5uint8_tstateFlight state
        6int16_tv_battbattery voltage
        8int16_tv_pyropyro battery voltage
        10int8_t[6]sensepyro continuity sense
        16int32_tground_presAverage barometer reading on ground
        20int16_tground_accelAverage accelerometer reading on ground
        22int16_taccel_plus_gAccel calibration at +1g
        24int16_taccel_minus_gAccel calibration at -1g
        26int16_taccelerationm/s² * 16
        28int16_tspeedm/s * 16
        30int16_theightm
        32   

        2.4. TeleMetrum v2 Sensor Data

        TypeDescription
        0x0ATeleMetrum v2 Sensor Data
        0x0BTeleMetrum v2 Calibration Data

        - TeleMetrum v2 has higher resolution barometric data than - TeleMetrum v1, and so the constant calibration data is - split out into a separate packet. -

        - TeleMetrum v2 Sensor Data packets are transmitted once per second on the - ground, 10 times per second during ascent and once per second - during descent and landing -

        - TeleMetrum v2 Calibration Data packets are always transmitted once per second. -

        Table 5. TeleMetrum v2 Sensor Packet Contents

        OffsetData TypeNameDescription
        5uint8_tstateFlight state
        6int16_taccelaccelerometer
        8int32_tprespressure sensor (Pa * 10)
        12int16_ttemptemperature sensor (°C * 100)
        14int16_taccelerationm/s² * 16
        16int16_tspeedm/s * 16
        18int16_theightm
        20int16_tv_battbattery voltage
        22int16_tsense_ddrogue continuity sense
        24int16_tsense_mmain continuity sense
        26pad[6]pad bytes 
        32   

        Table 6. TeleMetrum v2 Calibration Data Packet Contents

        OffsetData TypeNameDescription
        5pad[3]pad bytes 
        8int32_tground_presAverage barometer reading on ground
        12int16_tground_accelAverage accelerometer reading on ground
        14int16_taccel_plus_gAccel calibration at +1g
        16int16_taccel_minus_gAccel calibration at -1g
        18pad[14]pad bytes 
        32   

        2.5. Configuration Data

        TypeDescription
        0x04Configuration Data

        - This provides a description of the software installed on the - flight computer as well as any user-specified configuration data. -

        - Configuration data packets are transmitted once per second - during all phases of the flight -

        Table 7. Sensor Packet Contents

        OffsetData TypeNameDescription
        5uint8_ttypeDevice type
        6uint16_tflightFlight number
        8uint8_tconfig_majorConfig major version
        9uint8_tconfig_minorConfig minor version
        10uint16_tapogee_delayApogee deploy delay in seconds
        12uint16_tmain_deployMain deploy alt in meters
        14uint16_tflight_log_maxMaximum flight log size (kB)
        16charcallsign[8]Radio operator identifier
        24charversion[8]Software version identifier
        32   

        2.6. GPS Location

        TypeDescription
        0x05GPS Location

        - This packet provides all of the information available from the - GPS receiver—position, time, speed and precision - estimates. -

        - GPS Location packets are transmitted once per second during - all phases of the flight -

        Table 8. GPS Location Packet Contents

        OffsetData TypeNameDescription
        5uint8_tflagsSee GPS Flags table below
        6int16_taltitudem
        8int32_tlatitudedegrees * 107
        12int32_tlongitudedegrees * 107
        16uint8_tyear 
        17uint8_tmonth 
        18uint8_tday 
        19uint8_thour 
        20uint8_tminute 
        21uint8_tsecond 
        22uint8_tpdop* 5
        23uint8_thdop* 5
        24uint8_tvdop* 5
        25uint8_tmodeSee GPS Mode table below
        26uint16_tground_speedcm/s
        28int16_tclimb_ratecm/s
        30uint8_tcourse/ 2
        31uint8_tunused[1] 
        32   

        - Packed into a one byte field are status flags and the count of - satellites used to compute the position fix. Note that this - number may be lower than the number of satellites being - tracked; the receiver will not use information from satellites - with weak signals or which are close enough to the horizon to - have significantly degraded position accuracy. -

        Table 9. GPS Flags

        BitsNameDescription
        0-3nsatsNumber of satellites in solution
        4validGPS solution is valid
        5runningGPS receiver is operational
        6date_validReported date is valid
        7course_validground speed, course and climb rates are valid

        - Here are all of the valid GPS operational modes. Altus Metrum - products will only ever report 'N' (not valid), 'A' - (Autonomous) modes or 'E' (Estimated). The remaining modes - are either testing modes or require additional data. -

        Table 10. GPS Mode

        ModeNameDecsription
        NNot ValidAll data are invalid
        AAutonomous modeData are derived from satellite data
        DDifferential Mode - Data are augmented with differential data from a - known ground station. The SkyTraq unit in TeleMetrum - does not support this mode -
        EEstimated - Data are estimated using dead reckoning from the - last known data -
        MManualData were entered manually
        SSimulatedGPS receiver testing mode

        2.7. GPS Satellite Data

        TypeDescription
        0x06GPS Satellite Data

        - This packet provides space vehicle identifiers and signal - quality information in the form of a C/N1 number for up to 12 - satellites. The order of the svids is not specified. -

        - GPS Satellite data are transmitted once per second during all - phases of the flight. -

        Table 11. GPS Satellite Data Contents

        OffsetData TypeNameDescription
        5uint8_tchannelsNumber of reported satellite information
        6sat_info_tsats[12]See Per-Satellite data table below
        30uint8_tunused[2] 
        32   

        Table 12. GPS Per-Satellite data (sat_info_t)

        OffsetData TypeNameDescription
        0uint8_tsvidSpace Vehicle Identifier
        1uint8_tc_n_1C/N1 signal quality indicator
        2   

        2.8. Companion Data Data

        TypeDescription
        0x07Companion Data Data

        - When a companion board is attached to TeleMega or TeleMetrum, - it can provide telemetry data to be included in the - downlink. The companion board can provide up to 12 16-bit data - values. -

        - The companion board itself specifies the transmission rate. On - the ground and during descent, that rate is limited to one - packet per second. During ascent, that rate is limited to 10 - packets per second. -

        Table 13. Companion Data Contents

        OffsetData TypeNameDescription
        5uint8_tboard_idType of companion board attached
        6uint8_tupdate_periodHow often telemetry is sent, in 1/100ths of a second
        7uint8_tchannelsNumber of data channels supplied
        8uint16_t[12]companion_dataUp to 12 channels of 16-bit companion data
        32   

        3. Data Transmission

        - Altus Metrum devices use Texas Instruments sub-GHz digital radio - products. Ground stations use parts with HW FEC while some - flight computers perform FEC in software. TeleGPS is - transmit-only. -

        Table 14. Altus Metrum Radio Parts

        Part NumberDescriptionUsed in
        CC111110mW transceiver with integrated SoCTeleDongle v0.2, TeleBT v1.0, TeleMetrum v1.x, TeleMini
        CC112035mW transceiver with SW FECTeleMetrum v2, TeleMega
        CC120035mW transceiver with HW FECTeleDongle v3.0, TeleBT v3.0
        CC115L14mW transmitter with SW FECTeleGPS

        3.1. Modulation Scheme

        - Texas Instruments provides a tool for computing modulation - parameters given a desired modulation format and basic bit - rate. - - While we might like to use something with better low-signal - performance like BPSK, the radios we use don't support that, - but do support Gaussian frequency shift keying (GFSK). Regular - frequency shift keying (FSK) encodes the signal by switching - the carrier between two frequencies. The Gaussian version is - essentially the same, but the shift between frequencies gently - follows a gaussian curve, rather than switching - immediately. This tames the bandwidth of the signal without - affecting the ability to transmit data. - - For AltOS, there are three available bit rates, 38.4kBaud, - 9.6kBaud and 2.4kBaud resulting in the following signal - parmeters: - -

        Table 15. Modulation Scheme

        RateDeviationReceiver Bandwidth
        38.4kBaud20.5kHz100kHz
        9.6kBaud5.125kHz25kHz
        2.4kBaud1.5kHz5kHz

        3.2. Error Correction

        - The cc1111 and cc1200 provide forward error correction in - hardware; on the cc1120 and cc115l that's done in - software. AltOS uses this to improve reception of weak - signals. As it's a rate 1/2 encoding, each bit of data takes - two bits when transmitted, so the effective data rate is half - of the raw transmitted bit rate. -

        Table 16. Error Correction

        ParameterValueDescription
        Error CorrectionConvolutional coding1/2 rate, constraint length m=4
        Interleaving4 x 4Reduce effect of noise burst
        Data WhiteningXOR with 9-bit PNRRotate right with bit 8 = bit 0 xor bit 5, initial - value 111111111

        4. TeleDongle packet format

        - TeleDongle does not do any interpretation of the packet data, - instead it is configured to receive packets of a specified - length (32 bytes in this case). For each received packet, - TeleDongle produces a single line of text. This line starts with - the string "TELEM " and is followed by a list of hexadecimal - encoded bytes. - 

        TELEM 224f01080b05765e00701f1a1bbeb8d7b60b070605140c000600000000000000003fa988

        - The hexadecimal encoded string of bytes contains a length byte, - the packet data, two bytes added by the cc1111 radio receiver - hardware and finally a checksum so that the host software can - validate that the line was transmitted without any errors. -

        Table 17. Packet Format

        OffsetNameExampleDescription
        0length22Total length of data bytes in the line. Note that - this includes the added RSSI and status bytes
        1 ·· length-3packet4f ·· 00Bytes of actual packet data
        length-2rssi3fReceived signal strength. dBm = rssi / 2 - 74
        length-1lqia9Link Quality Indicator and CRC status. Bit 7 - is set when the CRC is correct
        lengthchecksum88(0x5a + sum(bytes 1 ·· length-1)) % 256

        5. History and Motivation

        - The original AltoOS telemetry mechanism encoded everything - available piece of information on the TeleMetrum hardware into a - single unified packet. Initially, the packets contained very - little data—some raw sensor readings along with the current GPS - coordinates when a GPS receiver was connected. Over time, the - amount of data grew to include sensor calibration data, GPS - satellite information and a host of internal state information - designed to help diagnose flight failures in case of a loss of - the on-board flight data. -

        - Because every packet contained all of the data, packets were - huge—95 bytes long. Much of the information was also specific to - the TeleMetrum hardware. With the introduction of the TeleMini - flight computer, most of the data contained in the telemetry - packets was unavailable. Initially, a shorter, but still - comprehensive packet was implemented. This required that the - ground station be pre-configured as to which kind of packet to - expect. -

        - The development of several companion boards also made the - shortcomings evident—each companion board would want to include - telemetry data in the radio link; with the original design, the - packet would have to hold the new data as well, requiring - additional TeleMetrum and ground station changes. -

        + +AltOS Telemetry

        AltOS Telemetry

        Packet Definitions

        Keith Packard

        Copyright © 2011 Keith Packard

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

        Table of Contents

        1. Packet Format Design
        2. Packet Formats
        2.1. Packet Header
        2.2. TeleMetrum v1.x, TeleMini v1.0 and TeleNano Sensor Data
        2.3. TeleMega Sensor Data
        2.4. TeleMetrum v2 Sensor Data
        2.5. TeleMini v3.0 Sensor Data
        2.6. Configuration Data
        2.7. GPS Location
        2.8. GPS Satellite Data
        2.9. Companion Data
        3. Data Transmission
        3.1. Modulation Scheme
        3.2. Error Correction
        4. TeleDongle serial packet format
        5. History and Motivation

        1. Packet Format Design

        AltOS telemetry data is split into multiple different packets, +all the same size, but each includs an identifier so that the +ground station can distinguish among different types. A single +flight board will transmit multiple packet types, each type on +a different schedule. The ground software need look for only a +single packet size, and then decode the information within the +packet and merge data from multiple packets to construct the +full flight computer state.

        Each AltOS packet is 32 bytes long. This size was chosen based +on the known telemetry data requirements. The power of two +size allows them to be stored easily in flash memory without +having them split across blocks or leaving gaps at the end.

        All packet types start with a five byte header which encodes +the device serial number, device clock value and the packet +type. The remaining 27 bytes encode type-specific data.

        2. Packet Formats

        This section first defines the packet header common to all packets +and then the per-packet data layout.

        2.1. Packet Header

        Table 1. Telemetry Packet Header

        Offset

        Data Type

        Name

        Description

        0

        uint16_t

        serial

        Device serial Number

        2

        uint16_t

        tick

        Device time in 100ths of a second

        4

        uint8_t

        type

        Packet type


        Each packet starts with these five bytes which serve to identify +which device has transmitted the packet, when it was transmitted +and what the rest of the packet contains.

        2.2. TeleMetrum v1.x, TeleMini v1.0 and TeleNano Sensor Data

        Table 2. Sensor Packet Type

        Type

        Description

        0x01

        TeleMetrum v1.x Sensor Data

        0x02

        TeleMini v1.0 Sensor Data

        0x03

        TeleNano Sensor Data


        TeleMetrum v1.x, TeleMini v1.0 and TeleNano share this same +packet format for sensor data. Each uses a distinct +packet type so that the receiver knows which data +values are valid and which are undefined.

        Sensor Data packets are transmitted once per second on +the ground, 10 times per second during ascent and once +per second during descent and landing

        Table 3. Sensor Packet Contents

        Offset

        Data Type

        Name

        Description

        5

        uint8_t

        state

        Flight state

        6

        int16_t

        accel

        accelerometer (TM only)

        8

        int16_t

        pres

        pressure sensor

        10

        int16_t

        temp

        temperature sensor

        12

        int16_t

        v_batt

        battery voltage

        14

        int16_t

        sense_d

        drogue continuity sense (TM/Tm)

        16

        int16_t

        sense_m

        main continuity sense (TM/Tm)

        18

        int16_t

        acceleration

        m/s² * 16

        20

        int16_t

        speed

        m/s * 16

        22

        int16_t

        height

        m

        24

        int16_t

        ground_pres

        Average barometer reading on ground

        26

        int16_t

        ground_accel

        TM

        28

        int16_t

        accel_plus_g

        TM

        30

        int16_t

        accel_minus_g

        TM


        2.3. TeleMega Sensor Data

        Table 4. TeleMega Packet Type

        Type

        Description

        0x08

        TeleMega IMU Sensor Data

        0x09

        TeleMega Kalman and Voltage Data


        TeleMega has a lot of sensors, and so it splits the sensor +data into two packets. The raw IMU data are sent more often; +the voltage values don’t change very fast, and the Kalman +values can be reconstructed from the IMU data.

        IMU Sensor Data packets are transmitted once per second on the +ground, 10 times per second during ascent and once per second +during descent and landing

        Kalman and Voltage Data packets are transmitted once per second on the +ground, 5 times per second during ascent and once per second +during descent and landing

        The high-g accelerometer is reported separately from the data +for the 9-axis IMU (accel/gyro/mag). The 9-axis IMU is mounted +so that the X axis is "across" the board (along the short +axis0, the Y axis is "along" the board (along the long axis, +with the high-g accelerometer) and the Z axis is "through" the +board (perpendicular to the board). Rotation measurements are +around the respective axis, so Y rotation measures the spin +rate of the rocket while X and Z rotation measure the tilt +rate.

        The overall tilt angle of the rocket is computed by first +measuring the orientation of the rocket on the pad using the 3 +axis accelerometer, and then integrating the overall tilt rate +from the 3 axis gyroscope to compute the total orientation +change of the airframe since liftoff.

        Table 5. TeleMega IMU Sensor Packet Contents

        Offset

        Data Type

        Name

        Description

        5

        uint8_t

        orient

        Angle from vertical in degrees

        6

        int16_t

        accel

        High G accelerometer

        8

        int32_t

        pres

        pressure (Pa * 10)

        12

        int16_t

        temp

        temperature (°C * 100)

        14

        int16_t

        accel_x

        X axis acceleration (across)

        16

        int16_t

        accel_y

        Y axis acceleration (along)

        18

        int16_t

        accel_z

        Z axis acceleration (through)

        20

        int16_t

        gyro_x

        X axis rotation (across)

        22

        int16_t

        gyro_y

        Y axis rotation (along)

        24

        int16_t

        gyro_z

        Z axis rotation (through)

        26

        int16_t

        mag_x

        X field strength (across)

        28

        int16_t

        mag_y

        Y field strength (along)

        30

        int16_t

        mag_z

        Z field strength (through)


        Table 6. TeleMega Kalman and Voltage Data Packet Contents

        Offset

        Data Type

        Name

        Description

        5

        uint8_t

        state

        Flight state

        6

        int16_t

        v_batt

        battery voltage

        8

        int16_t

        v_pyro

        pyro battery voltage

        10

        int8_t[6]

        sense

        pyro continuity sense

        16

        int32_t

        ground_pres

        Average barometer reading on ground

        20

        int16_t

        ground_accel

        Average accelerometer reading on ground

        22

        int16_t

        accel_plus_g

        Accel calibration at +1g

        24

        int16_t

        accel_minus_g

        Accel calibration at -1g

        26

        int16_t

        acceleration

        m/s² * 16

        28

        int16_t

        speed

        m/s * 16

        30

        int16_t

        height

        m


        2.4. TeleMetrum v2 Sensor Data

        Table 7. TeleMetrum v2 Packet Type

        Type

        Description

        0x0A

        TeleMetrum v2 Sensor Data

        0x0B

        TeleMetrum v2 Calibration Data


        TeleMetrum v2 has higher resolution barometric data than +TeleMetrum v1, and so the constant calibration data is +split out into a separate packet.

        TeleMetrum v2 Sensor Data packets are transmitted once per second on the +ground, 10 times per second during ascent and once per second +during descent and landing

        TeleMetrum v2 Calibration Data packets are always transmitted once per second.

        Table 8. TeleMetrum v2 Sensor Packet Contents

        Offset

        Data Type

        Name

        Description

        5

        uint8_t

        state

        Flight state

        6

        int16_t

        accel

        accelerometer

        8

        int32_t

        pres

        pressure sensor (Pa * 10)

        12

        int16_t

        temp

        temperature sensor (°C * 100)

        14

        int16_t

        acceleration

        m/s² * 16

        16

        int16_t

        speed

        m/s * 16

        18

        int16_t

        height

        m

        20

        int16_t

        v_batt

        battery voltage

        22

        int16_t

        sense_d

        drogue continuity sense

        24

        int16_t

        sense_m

        main continuity sense

        26

        pad[6]

        pad bytes


        Table 9. TeleMetrum v2 Calibration Data Packet Contents

        Offset

        Data Type

        Name

        Description

        5

        pad[3]

        pad bytes

        8

        int32_t

        ground_pres

        Average barometer reading on ground

        12

        int16_t

        ground_accel

        Average accelerometer reading on ground

        14

        int16_t

        accel_plus_g

        Accel calibration at +1g

        16

        int16_t

        accel_minus_g

        Accel calibration at -1g

        18

        pad[14]

        pad bytes


        2.5. TeleMini v3.0 Sensor Data

        Table 10. Sensor Packet Type

        Type

        Description

        0x11

        TeleMini v3.0 Sensor Data


        TeleMini v3.0 uses this +packet format for sensor data.

        Sensor Data packets are transmitted once per second on +the ground, 10 times per second during ascent and once +per second during descent and landing

        Table 11. Sensor Packet Contents

        Offset

        Data Type

        Name

        Description

        5

        uint8_t

        state

        Flight state

        6

        int16_t

        v_batt

        battery voltage

        8

        int16_t

        sense_a

        apogee continuity sense

        10

        int16_t

        sense_m

        main continuity sense

        12

        int32_t

        pres

        pressure sensor (Pa * 10)

        16

        int16_t

        temp

        temperature sensor (°C * 100)

        18

        int16_t

        acceleration

        m/s² * 16

        20

        int16_t

        speed

        m/s * 16

        22

        int16_t

        height

        m

        24

        int16_t

        ground_pres

        Average barometer reading on ground

        28

        pad[4]

        pad bytes


        2.6. Configuration Data

        Table 12. Configuration Packet Type

        Type

        Description

        0x04

        Configuration Data


        This provides a description of the software installed on the +flight computer as well as any user-specified configuration data.

        Configuration data packets are transmitted once per second +during all phases of the flight

        Table 13. Configuration Packet Contents

        Offset

        Data Type

        Name

        Description

        5

        uint8_t

        type

        Device type

        6

        uint16_t

        flight

        Flight number

        8

        uint8_t

        config_major

        Config major version

        9

        uint8_t

        config_minor

        Config minor version

        10

        uint16_t

        apogee_delay

        Apogee deploy delay in seconds

        12

        uint16_t

        main_deploy

        Main deploy alt in meters

        14

        uint16_t

        flight_log_max

        Maximum flight log size (kB)

        16

        char

        callsign[8]

        Radio operator identifier

        24

        char

        version[8]

        Software version identifier


        2.7. GPS Location

        Table 14. GPS Packet Type

        Type

        Description

        0x05

        GPS Location


        This packet provides all of the information available from the +GPS receiver—position, time, speed and precision +estimates.

        GPS Location packets are transmitted once per second during +all phases of the flight

        Table 15. GPS Location Packet Contents

        Offset

        Data Type

        Name

        Description

        5

        uint8_t

        flags

        See GPS Flags table below

        6

        int16_t

        altitude

        m

        8

        int32_t

        latitude

        degrees * 107

        12

        int32_t

        longitude

        degrees * 107

        16

        uint8_t

        year

        17

        uint8_t

        month

        18

        uint8_t

        day

        19

        uint8_t

        hour

        20

        uint8_t

        minute

        21

        uint8_t

        second

        22

        uint8_t

        pdop

        * 5

        23

        uint8_t

        hdop

        * 5

        24

        uint8_t

        vdop

        * 5

        25

        uint8_t

        mode

        See GPS Mode table below

        26

        uint16_t

        ground_speed

        cm/s

        28

        int16_t

        climb_rate

        cm/s

        30

        uint8_t

        course

        / 2

        31

        uint8_t

        unused[1]


        Packed into a one byte field are status flags and the +count of satellites used to compute the position +fix. Note that this number may be lower than the +number of satellites being tracked; the receiver will +not use information from satellites with weak signals +or which are close enough to the horizon to have +significantly degraded position accuracy.

        Table 16. GPS Flags

        Bits

        Name

        Description

        0-3

        nsats

        Number of satellites in solution

        4

        valid

        GPS solution is valid

        5

        running

        GPS receiver is operational

        6

        date_valid

        Reported date is valid

        7

        course_valid

        ground speed, course and climb rates are valid


        Here are all of the valid GPS operational modes. Altus +Metrum products will only ever report N (not valid), +A (Autonomous) modes or E (Estimated). The +remaining modes are either testing modes or require +additional data.

        Table 17. GPS Mode

        Mode

        Name

        Description

        N

        Not Valid

        All data are invalid

        A

        Autonomous mode

        Data are derived from satellite data

        D

        Differential Mode

        Data are augmented with differential data from a +known ground station. The SkyTraq unit in TeleMetrum +does not support this mode

        E

        Estimated

        Data are estimated using dead reckoning from the +last known data

        M

        Manual

        Data were entered manually

        S

        Simulated

        GPS receiver testing mode


        2.8. GPS Satellite Data

        Table 18. GPS Satellite Data Packet Type

        Type

        Description

        0x06

        GPS Satellite Data


        This packet provides space vehicle identifiers and +signal quality information in the form of a C/N1 +number for up to 12 satellites. The order of the svids +is not specified.

        GPS Satellite data are transmitted once per second +during all phases of the flight.

        Table 19. GPS Satellite Data Contents

        Offset

        Data Type

        Name

        Description

        5

        uint8_t

        channels

        Number of reported satellite information

        6

        sat_info_t

        sats[12]

        See Per-Satellite data table below

        30

        uint8_t

        unused[2]


        Table 20. GPS Per-Satellite data (sat_info_t)

        Offset

        Data Type

        Name

        Description

        0

        uint8_t

        svid

        Space Vehicle Identifier

        1

        uint8_t

        c_n_1

        C/N1 signal quality indicator


        2.9. Companion Data

        Table 21. Companion Data Packet Type

        Type

        Description

        0x07

        Companion Data


        When a companion board is attached to TeleMega or +TeleMetrum, it can provide telemetry data to be +included in the downlink. The companion board can +provide up to 12 16-bit data values.

        The companion board itself specifies the transmission +rate. On the ground and during descent, that rate is +limited to one packet per second. During ascent, that +rate is limited to 10 packets per second.

        Table 22. Companion Data Contents

        Offset

        Data Type

        Name

        Description

        5

        uint8_t

        board_id

        Type of companion board attached

        6

        uint8_t

        update_period

        How often telemetry is sent, in 1/100ths of a second

        7

        uint8_t

        channels

        Number of data channels supplied

        8

        uint16_t[12]

        companion_data

        Up to 12 channels of 16-bit companion data


        3. Data Transmission

        Altus Metrum devices use Texas Instruments sub-GHz digital +radio products. Ground stations use parts with HW FEC while +some flight computers perform FEC in software. TeleGPS is +transmit-only.

        Table 23. Altus Metrum Radio Parts

        Part Number

        Description

        Used in

        CC1111

        10mW transceiver with integrated SoC

        TeleDongle v0.2, TeleBT v1.0, TeleMetrum v1.x, TeleMini

        CC1120

        35mW transceiver with SW FEC

        TeleMetrum v2, TeleMega

        CC1200

        35mW transceiver with HW FEC

        TeleDongle v3.0, TeleBT v3.0

        CC115L

        14mW transmitter with SW FEC

        TeleGPS


        3.1. Modulation Scheme

        Texas Instruments provides a tool for computing +modulation parameters given a desired modulation +format and basic bit rate.

        While we might like to use something with better +low-signal performance like BPSK, the radios we use +don’t support that, but do support Gaussian frequency +shift keying (GFSK). Regular frequency shift keying +(FSK) encodes the signal by switching the carrier +between two frequencies. The Gaussian version is +essentially the same, but the shift between +frequencies gently follows a gaussian curve, rather +than switching immediately. This tames the bandwidth +of the signal without affecting the ability to +transmit data.

        For AltOS, there are three available bit rates, +38.4kBaud, 9.6kBaud and 2.4kBaud resulting in the +following signal parmeters:

        Table 24. Modulation Scheme

        Rate

        Deviation

        Receiver Bandwidth

        38.4kBaud

        20.5kHz

        100kHz

        9.6kBaud

        5.125kHz

        25kHz

        2.4kBaud

        1.5kHz

        5kHz


        3.2. Error Correction

        The cc1111 and cc1200 provide forward error correction +in hardware; on the cc1120 and cc115l that’s done in +software. AltOS uses this to improve reception of weak +signals. As it’s a rate 1/2 encoding, each bit of data +takes two bits when transmitted, so the effective data +rate is half of the raw transmitted bit rate.

        Table 25. Error Correction

        Parameter

        Value

        Description

        Error Correction

        Convolutional coding

        1/2 rate, constraint length m=4

        Interleaving

        4 x 4

        Reduce effect of noise burst

        Data Whitening

        XOR with 9-bit PNR

        Rotate right with bit 8 = bit 0 xor bit 5, initial value 111111111


        4. TeleDongle serial packet format

        TeleDongle does not do any interpretation of the packet data, +instead it is configured to receive packets of a specified +length (32 bytes in this case). For each received packet, +TeleDongle produces a single line of text. This line starts with +the string "TELEM " and is followed by a list of hexadecimal +encoded bytes.

        TELEM 224f01080b05765e00701f1a1bbeb8d7b60b070605140c000600000000000000003fa988

        The hexadecimal encoded string of bytes contains a length byte, +the packet data, two bytes added by the cc1111 radio receiver +hardware and finally a checksum so that the host software can +validate that the line was transmitted without any errors.

        Table 26. TeleDongle serial Packet Format

        Offset

        Name

        Example

        Description

        0

        length

        22

        Total length of data bytes in the line. Note that +this includes the added RSSI and status bytes

        1 ·· length-3

        packet

        4f ·· 00

        Bytes of actual packet data

        length-2

        rssi

        3f

        Received signal strength. dBm = rssi / 2 - 74

        length-1

        lqi

        a9

        Link Quality Indicator and CRC status. Bit 7 +is set when the CRC is correct

        length

        checksum

        88

        (0x5a + sum(bytes 1 ·· length-1)) % 256


        5. History and Motivation

        The original AltoOS telemetry mechanism encoded everything +available piece of information on the TeleMetrum hardware into a +single unified packet. Initially, the packets contained very +little data—some raw sensor readings along with the current GPS +coordinates when a GPS receiver was connected. Over time, the +amount of data grew to include sensor calibration data, GPS +satellite information and a host of internal state information +designed to help diagnose flight failures in case of a loss of +the on-board flight data.

        Because every packet contained all of the data, packets were +huge—95 bytes long. Much of the information was also specific to +the TeleMetrum hardware. With the introduction of the TeleMini +flight computer, most of the data contained in the telemetry +packets was unavailable. Initially, a shorter, but still +comprehensive packet was implemented. This required that the +ground station be pre-configured as to which kind of packet to +expect.

        The development of several companion boards also made the +shortcomings evident—each companion board would want to include +telemetry data in the radio link; with the original design, the +packet would have to hold the new data as well, requiring +additional TeleMetrum and ground station changes.

        \ No newline at end of file diff --git a/AltOS/doc/telemetry.pdf b/AltOS/doc/telemetry.pdf index e17d772..9c0a21e 100644 Binary files a/AltOS/doc/telemetry.pdf and b/AltOS/doc/telemetry.pdf differ diff --git a/AltOS/doc/telemini-v1-outline.pdf b/AltOS/doc/telemini-v1-outline.pdf index c513a55..e69de29 100644 Binary files a/AltOS/doc/telemini-v1-outline.pdf and b/AltOS/doc/telemini-v1-outline.pdf differ diff --git a/AltOS/doc/telemini-v3-outline.pdf b/AltOS/doc/telemini-v3-outline.pdf index 3c8b4ee..e69de29 100644 Binary files a/AltOS/doc/telemini-v3-outline.pdf and b/AltOS/doc/telemini-v3-outline.pdf differ