From f0542085de2139ef562af068ec05fa73f47c73b1 Mon Sep 17 00:00:00 2001 From: Keith Packard Date: Fri, 19 Nov 2010 20:26:49 +0800 Subject: doc: Add preliminary altosui documentation Also, update the Makefile to allow for further documents to be added without a lot of custom rules. Signed-off-by: Keith Packard --- doc/Makefile | 37 ++++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 17 deletions(-) (limited to 'doc/Makefile') diff --git a/doc/Makefile b/doc/Makefile index 238cefb0..57300c10 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -2,32 +2,35 @@ # http://docbook.sourceforge.net/release/xsl/current/README # -all: telemetrum-doc.html telemetrum-doc.pdf +HTML=telemetrum-doc.html altosui-doc.html +PDF=telemetrum-doc.pdf altosui-doc.pdf +DOC=$(HTML) $(PDF) +HTMLSTYLE=/usr/share/xml/docbook/stylesheet/docbook-xsl/html/docbook.xsl +FOSTYLE=/usr/share/xml/docbook/stylesheet/docbook-xsl/fo/docbook.xsl +PDFSTYLE= -publish: all - cp telemetrum-doc.html \ - telemetrum-doc.pdf /home/bdale/web/altusmetrum/TeleMetrum/doc/ - (cd /home/bdale/web/altusmetrum ; echo "update docs" | git commit -F - /home/bdale/web/altusmetrum/TeleMetrum/doc/* ; git push) +.SUFFIXES: .xsl .html .fo .pdf + +.xsl.html: + xsltproc -o $@ $(HTMLSTYLE) $*.xsl +.xsl.fo: + xsltproc -o $@ $(FOSTYLE) $*.xsl -telemetrum-doc.html: telemetrum-doc.xsl - xsltproc -o telemetrum-doc.html \ - /usr/share/xml/docbook/stylesheet/docbook-xsl/html/docbook.xsl \ - telemetrum-doc.xsl +.fo.pdf: + fop -fo $*.fo -pdf $@ -telemetrum-doc.fo: telemetrum-doc.xsl - xsltproc -o telemetrum-doc.fo \ - /usr/share/xml/docbook/stylesheet/docbook-xsl/fo/docbook.xsl \ - telemetrum-doc.xsl +all: $(HTML) $(PDF) -telemetrum-doc.pdf: telemetrum-doc.fo - fop -fo telemetrum-doc.fo -pdf telemetrum-doc.pdf +publish: $(DOC) + cp $(DOC)telemetrum-doc.html home/bdale/web/altusmetrum/TeleMetrum/doc/ + (cd /home/bdale/web/altusmetrum ; echo "update docs" | git commit -F - /home/bdale/web/altusmetrum/TeleMetrum/doc/* ; git push) clean: - rm -f telemetrum-doc.html telemetrum-doc.pdf telemetrum-doc.fo + rm -f *.html *.pdf *.fo distclean: - rm -f telemetrum-doc.html telemetrum-doc.pdf telemetrum-doc.fo + rm -f *.html *.pdf *.fo indent: telemetrum-doc.xsl xmlindent -i 2 < telemetrum-doc.xsl > telemetrum-doc.new -- cgit v1.2.3 From 737f2fdd012202f453120ece117ae5e859b32082 Mon Sep 17 00:00:00 2001 From: Keith Packard Date: Mon, 22 Nov 2010 22:26:19 -0800 Subject: doc: Add internal documentation for AltOS Signed-off-by: Keith Packard --- doc/Makefile | 4 +- doc/altos.xsl | 1441 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 1443 insertions(+), 2 deletions(-) create mode 100644 doc/altos.xsl (limited to 'doc/Makefile') diff --git a/doc/Makefile b/doc/Makefile index 57300c10..52934290 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -2,8 +2,8 @@ # http://docbook.sourceforge.net/release/xsl/current/README # -HTML=telemetrum-doc.html altosui-doc.html -PDF=telemetrum-doc.pdf altosui-doc.pdf +HTML=telemetrum-doc.html altosui-doc.html altos.html +PDF=telemetrum-doc.pdf altosui-doc.pdf altos.pdf DOC=$(HTML) $(PDF) HTMLSTYLE=/usr/share/xml/docbook/stylesheet/docbook-xsl/html/docbook.xsl FOSTYLE=/usr/share/xml/docbook/stylesheet/docbook-xsl/fo/docbook.xsl diff --git a/doc/altos.xsl b/doc/altos.xsl new file mode 100644 index 00000000..9a88a5b5 --- /dev/null +++ b/doc/altos.xsl @@ -0,0 +1,1441 @@ + + + + + AltOS + Altos Metrum Operating System + + + Keith + Packard + + + 2010 + Keith Packard + + + + This document is released under the terms of the + + Creative Commons ShareAlike 3.0 + + license. + + + + + 0.1 + 22 November 2010 + Initial content + + + + + Overview + + AltOS is a operating system built for the 8051-compatible + processor found in the TI cc1111 microcontroller. It's designed + to be small and easy to program with. The main features are: + + + Multi-tasking. While the 8051 doesn'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. + + + + 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. + +
+ 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. + + + SDCC 8051 memory spaces + + __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. + + + + + __idata + + + There are an additional 128 bytes of internal memory + that share the same address space as __data but which + cannot be directly addressed. The stack normally + occupies this space and so AltOS doesn't place any + static storage here. + + + + + __xdata + + + This is additional general memory accessed through a + single 16-bit address register. The CC1111F32 has 32kB + of memory available here. Most program data should live + in this memory space. + + + + + __pdata + + + This is an alias for the first 256 bytes of __xdata + memory, but uses a shorter addressing mode with + single global 8-bit value for the high 8 bits of the + address and any of several 8-bit registers for the low 8 + bits. AltOS uses a few bits of this memory, it should + probably use more. + + + + + __code + + + All executable code must live in this address space, but + you can stick read-only data here too. It is addressed + using the 16-bit address register and special 'code' + access opcodes. Anything read-only should live in this space. + + + + + __bit + + + The 8051 has 128 bits of bit-addressible memory that + lives in the __data segment from 0x20 through + 0x2f. Special instructions access these bits + in a single atomic operation. This isn't so much a + separate address space as a special addressing mode for + a few bytes in the __data segment. + + + + + __sfr, __sfr16, __sfr32, __sbit + + + Access to physical registers in the device use this mode + which declares the variable name, it's type and the + address it lives at. No memory is allocated for these + variables. + + + + +
+
+ Function calls on the 8051 + + 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. + +
+ __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. + +
+
+ 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. + +
+
+ __interrupt functions + + Interrupt functions are declared with with an __interrupt + decoration that includes the interrupt number. SDCC saves + and restores all of the registers in these functions and + uses the 'reti' instruction at the end so that they operate + as stand-alone interrupt handlers. Interrupt functions may + call the ao_wakeup function to wake AltOS tasks. + +
+
+ __critical functions and statements + + 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. + +
+
+ + + Task functions + + This chapter documents how to create, destroy and schedule AltOS tasks. + + + AltOS Task Functions + + 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. + + + + + ao_exit + + +void +ao_exit(void) + + + This terminates the current task. + + + + + 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. + + + + + 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. + + + + + ao_alarm + + +void +ao_alarm(uint16_t delay) + + + 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_wake_task + + +void +ao_wake_task(__xdata struct ao_task *task) + + + Force a specific task to wake up, independent of which + 'wchan' it is waiting for. + + + + + ao_start_scheduler + + +void +ao_start_scheduler(void) + + + This is called from 'main' when the system is all + initialized and ready to run. It will not return. + + + + + ao_clock_init + + +void +ao_clock_init(void) + + + This turns on the external 48MHz clock then switches the + hardware to using it. This is required by many of the + internal devices like USB. It should be called by the + 'main' function first, before initializing any of the + other devices in the system. + + + + + + + Timer Functions + + AltOS sets up one of the cc1111 timers to run at 100Hz and + exposes this tick as the fundemental unit of time. At each + interrupt, AltOS increments the counter, and schedules any tasks + waiting for that time to pass, then fires off the ADC system to + collect current data readings. Doing this from the ISR ensures + that the ADC values are sampled at a regular rate, independent + of any scheduling jitter. + + + AltOS Timer Functions + + ao_time + + +uint16_t +ao_time(void) + + + Returns the current system tick count. Note that this is + only a 16 bit value, and so it wraps every 655.36 seconds. + + + + + ao_delay + + +void +ao_delay(uint16_t ticks); + + + Suspend the current task for at least 'ticks' clock units. + + + + + ao_timer_set_adc_interval + + +void +ao_timer_set_adc_interval(uint8_t interval); + + + This sets the number of ticks between ADC samples. If set + to 0, no ADC samples are generated. AltOS uses this to + slow down the ADC sampling rate to save power. + + + + + ao_timer_init + + +void +ao_timer_init(void) + + + This turns on the 100Hz tick using the CC1111 timer 1. It + is required for any of the time-based functions to + work. It should be called by 'main' before ao_start_scheduler. + + + + + + + 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. + + + Mutex Functions + + ao_mutex_get + + +void +ao_mutex_get(__xdata uint8_t *mutex); + + + Acquires the specified mutex, blocking if the mutex is + owned by another task. + + + + + ao_mutex_put + + +void +ao_mutex_put(__xdata uint8_t *mutex); + + + Releases the specified mutex, waking up all tasks waiting + for it. + + + + + + + CC1111 DMA engine + + The CC1111 contains a useful bit of extra hardware in the form + of five programmable DMA engines. They can be configured to copy + data in memory, or between memory and devices (or even between + two devices). AltOS exposes a general interface to this hardware + and uses it to handle radio and SPI data. + + + 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. + + + AltOS DMA functions + + ao_dma_alloc + + +uint8_t +ao_dma_alloc(__xdata uint8_t *done) + + + Allocates a DMA engine, returning the identifier. Whenever + this DMA engine completes a transfer. '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. + + + + + 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. + + + + + ao_dma_start + + +void +ao_dma_start(uint8_t id); + + + Arm the specified DMA engine and await a signal from + either hardware or software to start transferring data. + + + + + ao_dma_trigger + + +void +ao_dma_trigger(uint8_t id) + + + Trigger the specified DMA engine to start copying data. + + + + + ao_dma_abort + + +void +ao_dma_abort(uint8_t id) + + + Terminate any in-progress DMA transation, marking its + 'done' variable with the AO_DMA_ABORTED bit. + + + + + + + SDCC Stdio interface + + AltOS offers a stdio interface over both USB and the RF packet + link. This provides for control of the device localy or + remotely. This is hooked up to the stdio functions in SDCC by + providing the standard putchar/getchar/flush functions. These + automatically multiplex the two available communication + channels; output is always delivered to the channel which + provided the most recent input. + + + SDCC stdio functions + + putchar + + +void +putchar(char c) + + + Delivers a single character to the current console + device. + + + + + 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. + + + + + flush + + +void +flush(void) + + + Flushes the current console device output buffer. Any + pending characters will be delivered to the target device. +xo + + + + ao_add_stdio + + +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. + + + + + + + Command line interface + + AltOS includes a simple command line parser which is hooked up + to the stdio interfaces permitting remote control of the device + over USB or the RF link as desired. Each command uses a single + character to invoke it, the remaining characters on the line are + available as parameters to the command. + + + AltOS command line parsing functions + + 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. + + + + + + + + + ao_cmd_lex + + +void +ao_cmd_lex(void); + + + This gets the next character out of the command line + buffer and sticks it into ao_cmd_lex_c. At the end of the + line, ao_cmd_lex_c will get a newline ('\n') character. + + + + + ao_cmd_put16 + + +void +ao_cmd_put16(uint16_t v); + + + Writes 'v' as four hexadecimal characters. + + + + + ao_cmd_put8 + + +void +ao_cmd_put8(uint8_t v); + + + Writes 'v' as two hexadecimal characters. + + + + + ao_cmd_white + + +void +ao_cmd_white(void) + + + This skips whitespace by calling ao_cmd_lex while + ao_cmd_lex_c is either a space or tab. It does not skip + any characters if ao_cmd_lex_c already non-white. + + + + + ao_cmd_hex + + +void +ao_cmd_hex(void) + + + This reads a 16-bit hexadecimal value from the command + line with optional leading whitespace. The resulting value + is stored in ao_cmd_lex_i; + + + + + ao_cmd_decimal + + +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; + + + + + 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. + + + + + 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. + + + + + + + CC1111 USB target device + + The CC1111 contains a full-speed USB target device. It can be + programmed to offer any kind of USB target, but to simplify + interactions with a variety of operating systems, AltOS provides + 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. + + + AltOS USB functions + + 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. + + + + + 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. + + + + + 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. + + + + + ao_usb_getchar + + +char +ao_usb_getchar(void); + + + This uses ao_pollchar to receive the next character, + blocking while ao_pollchar returns AO_READ_AGAIN. + + + + + ao_usb_disable + + +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. + + + + + 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. + + + + + 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. + + + + + + + CC1111 Serial peripheral + + The CC1111 provides two USART peripherals. AltOS uses one for + asynch serial data, generally to communicate with a GPS device, + and the other for a SPI bus. The UART is configured to operate + 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. + + + AltOS serial functions + + ao_serial_getchar + + +char +ao_serial_getchar(void); + + + Returns the next character from the receive fifo, blocking + until a character is received if the fifo is empty. + + + + + ao_serial_putchar + + +void +ao_serial_putchar(char c); + + + Adds a character to the transmit fifo, blocking if the + fifo is full. Starts transmitting characters. + + + + + ao_serial_drain + + +void +ao_serial_drain(void); + + + Blocks until the transmit fifo is empty. Used internally + when changing serial speeds. + + + + + 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. + + + + + 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. + + + + + + + CC1111 Radio peripheral + + The CC1111 radio transceiver sends and receives digital packets + with forward error correction and detection. The AltOS driver is + fairly specific to the needs of the TeleMetrum and TeleDongle + devices, using it for other tasks may require customization of + the driver itself. There are three basic modes of operation: + + + + 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. + + + + + 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. + + + + + 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. + + + + + + AltOS radio functions + + 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. + + + + + 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. + + + + + 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. + + + + + ao_radio_idle + + +void +ao_radio_idle(void); + + + Sets the radio device to idle mode, waiting until it reaches + that state. This will terminate any in-progress transmit or + receive operation. + + + + + ao_radio_get + + +void +ao_radio_get(void); + + + Acquires the radio mutex and then configures the radio + frequency using the global radio calibration and channel + values. + + + + + ao_radio_put + + +void +ao_radio_put(void); + + + Releases the radio mutex. + + + + + 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. + + + + + + AltOS radio telemetry functions + + 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. + + + 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. + + + + + 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()). + + + + + + AltOS radio direction finding function + + In radio direction finding mode, there's just one function to + use + + + 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. + + + + + + Packet mode functions + + 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. + + + 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. + + + + + ao_packet_pollchar + + +char +ao_packet_pollchar(void); + + + This returns a pending input character if available, + otherwise returns AO_READ_AGAIN. On the master side, if + this empties the buffer, it triggers a poll for more data. + + + + + ao_packet_slave_start + + +void +ao_packet_slave_start(void); + + + This is available only on the slave side and starts a task + to listen for packet data. + + + + + ao_packet_slave_stop + + +void +ao_packet_slave_stop(void); + + + Disables the packet slave task, stopping the radio receiver. + + + + + ao_packet_slave_init + + +void +ao_packet_slave_init(void); + + + Adds the packet stdio functions to the stdio package so + that when packet slave mode is enabled, characters will + get send and received through the stdio functions. + + + + + ao_packet_master_init + + +void +ao_packet_master_init(void); + + + Adds the 'p' packet forward command to start packet mode. + + + + + + -- cgit v1.2.3 From 853b7112e34212040c4cb7289f9cfdb2f3ea9f90 Mon Sep 17 00:00:00 2001 From: Bdale Garbee Date: Tue, 23 Nov 2010 18:53:18 -0700 Subject: merge Keith's AltosUI documention into "the big book" --- doc/Makefile | 4 +- doc/altosui-doc.xsl | 596 ------------------ doc/telemetrum-doc.xsl | 1629 ++++++++++++++++++++++++++++++++---------------- 3 files changed, 1099 insertions(+), 1130 deletions(-) delete mode 100644 doc/altosui-doc.xsl (limited to 'doc/Makefile') diff --git a/doc/Makefile b/doc/Makefile index 52934290..65917ea2 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -2,8 +2,8 @@ # http://docbook.sourceforge.net/release/xsl/current/README # -HTML=telemetrum-doc.html altosui-doc.html altos.html -PDF=telemetrum-doc.pdf altosui-doc.pdf altos.pdf +HTML=telemetrum-doc.html altos.html +PDF=telemetrum-doc.pdf altos.pdf DOC=$(HTML) $(PDF) HTMLSTYLE=/usr/share/xml/docbook/stylesheet/docbook-xsl/html/docbook.xsl FOSTYLE=/usr/share/xml/docbook/stylesheet/docbook-xsl/fo/docbook.xsl diff --git a/doc/altosui-doc.xsl b/doc/altosui-doc.xsl deleted file mode 100644 index 4a1f43b5..00000000 --- a/doc/altosui-doc.xsl +++ /dev/null @@ -1,596 +0,0 @@ - - - - - AltosUI - Altos Metrum Graphical User Interface Manual - - - Bdale - Garbee - - - Keith - Packard - - - 2010 - Bdale Garbee and Keith Packard - - - - This document is released under the terms of the - - Creative Commons ShareAlike 3.0 - - license. - - - - - 0.1 - 19 November 2010 - Initial content - - - - - Introduction - - The AltosUI program provides a graphical user interface for - interacting with the Altus Metrum product family, including - TeleMetrum and TeleDongle. AltosUI can monitor telemetry data, - configure TeleMetrum and TeleDongle devices and many other - tasks. The primary interface window provides a selection of - buttons, one for each major activity in the system. This manual - is split into chapters, each of which documents one of the tasks - provided from the top-level toolbar. - - - - Packet Command Mode - Controlling TeleMetrum Over The Radio Link - - One of the unique features of the Altos Metrum environment is - the ability to create a two way command link between TeleDongle - and TeleMetrum using the digital radio transceivers built into - each device. This allows you to interact with TeleMetrum from - afar, as if it were directly connected to the computer. - - - Any operation which can be performed with TeleMetrum - can either be done with TeleMetrum directly connected to - the computer via the USB cable, or through the packet - link. Simply select the appropriate TeleDongle device when - the list of devices is presented and AltosUI will use packet - command mode. - - - - - Save Flight Data—Recover flight data from the rocket without - opening it up. - - - - - Configure TeleMetrum—Reset apogee delays or main deploy - heights to respond to changing launch conditions. You can - also 'reboot' the TeleMetrum device. Use this to remotely - enable the flight computer by turning TeleMetrum on while - horizontal, then once the airframe is oriented for launch, - you can reboot TeleMetrum and have it restart in pad mode - without having to climb the scary ladder. - - - - - Fire Igniters—Test your deployment charges without snaking - wires out through holes in the airframe. Simply assembly the - rocket as if for flight with the apogee and main charges - loaded, then remotely command TeleMetrum to fire the - igniters. - - - - - Packet command mode uses the same RF channels as telemetry - mode. Configure the desired TeleDongle channel using the - flight monitor window channel selector and then close that - window before performing the desired operation. - - - TeleMetrum only enables packet command mode in 'idle' mode, so - make sure you have TeleMetrum lying horizontally when you turn - it on. Otherwise, TeleMetrum will start in 'pad' mode ready for - flight and will not be listening for command packets from TeleDongle. - - - When packet command mode is enabled, you can monitor the link - by watching the lights on the TeleDongle and TeleMetrum - devices. The red LED will flash each time TeleDongle or - TeleMetrum transmit a packet while the green LED will light up - on TeleDongle while it is waiting to receive a packet from - TeleMetrum. - - - - Monitor Flight - Receive, Record and Display Telemetry Data - - Selecting this item brings up a dialog box listing all of the - connected TeleDongle devices. When you choose one of these, - AltosUI will create a window to display telemetry data as - received by the selected TeleDongle device. - - - 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 channel being monitored by the TeleDongle device is - displayed at the top of the window. You can configure the - channel by clicking on the channel box and selecting the desired - channel. AltosUI remembers the last channel selected for each - TeleDongle and selects that automatically the next time you use - that device. - - - Below the TeleDongle channel selector, the window contains a few - significant pieces of information about the TeleMetrum providing - the telemetry data stream: - - - - The TeleMetrum callsign - - - The TeleMetrum serial number - - - The flight number. Each TeleMetrum remembers how many - times it has flown. - - - - The rocket flight state. Each flight passes through several - states including Pad, Boost, Fast, Coast, Drogue, Main and - Landed. - - - - - The Received Signal Strength Indicator value. This lets - you know how strong a signal TeleDongle is receiving. The - radio inside TeleDongle operates down to about -99dBm; - weaker signals may not be receiveable. The packet link uses - error correction and detection techniques which prevent - incorrect data from being reported. - - - - - Finally, the largest portion of the window contains a set of - tabs, each of which contain some information about the rocket. - They're arranged in 'flight order' so that as the flight - progresses, the selected tab 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 contains all of - the telemetry data in one place. - -
- Launch Pad - - The 'Launch Pad' tab shows information used to decide when the - rocket is ready for flight. The first elements include red/green - indicators, if any of these is red, you'll want to evaluate - whether the rocket is ready to launch: - - - - Battery Voltage. This indicates whether the LiPo battery - powering the TeleMetrum has sufficient charge to last for - the duration of the flight. A value of more than - 3.7V is required for a 'GO' status. - - - - - Apogee Igniter Voltage. This indicates whether the apogee - igniter has continuity. If the igniter has a low - resistance, then the voltage measured here will be close - to the LiPo battery voltage. A value greater than 3.2V is - required for a 'GO' status. - - - - - Main Igniter Voltage. This indicates whether the main - igniter has continuity. If the igniter has a low - resistance, then the voltage measured here will be close - to the LiPo battery voltage. A value greater than 3.2V is - required for a 'GO' status. - - - - - GPS Locked. This indicates whether the GPS receiver is - currently able to compute position information. GPS requires - at least 4 satellites to compute an accurate position. - - - - - GPS Ready. This indicates whether GPS has reported at least - 10 consecutive positions without losing lock. This ensures - that the 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. - - -
-
- Ascent - - 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 and acceleration are shown along with the - maxium values for each of them. This allows you to quickly - answer the most commonly asked questions you'll hear during - flight. - - - The current latitude and longitude reported by the GPS are - also shown. Note that under high acceleration, these values - 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. - -
-
- Descent - - Once the rocket has reached apogee and (we hope) activated the - apogee charge, attention switches to tracking the rocket on - the way back to the ground, and for dual-deploy flights, - waiting for the main charge to fire. - - - To monitor whether the apogee charge operated correctly, the - current descent rate is reported along with the current - height. Good descent rates generally range from 15-30m/s. - - - To help locate the rocket in the sky, use the elevation and - bearing information to figure out where to look. Elevation is - in degrees above the horizon. Bearing is reported in degrees - relative to true north. Range can help figure out how big the - rocket will appear. Note that all of these values are relative - to the pad location. If the elevation is near 90°, the rocket - is over the pad, not over you. - - - Finally, the igniter voltages are reported in this tab as - well, both to monitor the main charge as well as to see what - the status of the apogee charge is. - -
-
- Landed - - Once the rocket is on the ground, attention switches to - recovery. While the radio signal is generally lost once the - rocket is on the ground, the last reported GPS position is - generally within a short distance of the actual landing location. - - - The last reported GPS position is reported both by - latitude and longitude as well as a bearing and distance from - the launch pad. The distance should give you a good idea of - whether you'll want to walk or hitch a ride. Take the reported - latitude and longitude and enter them into your handheld GPS - unit and have that compute a track to the landing location. - - - Finally, the maximum height, speed and acceleration reported - during the flight are displayed for your admiring observers. - -
- - - Save Flight Data - - TeleMetrum records flight data to its internal flash memory. - This data is recorded at a much higher rate than the telemetry - system can handle, and is not subject to radio drop-outs. As - such, it provides a more complete and precise record of the - flight. The 'Save Flight Data' button allows you to read the - flash memory and write it to disk. - - - Clicking on the 'Save Flight Data' button brings up a list of - connected TeleMetrum and TeleDongle devices. If you select a - TeleMetrum device, the flight data will be downloaded from that - device directly. If you select a TeleDongle device, flight data - will be downloaded from a TeleMetrum device connected via the - packet command link to the specified TeleDongle. See the chapter - on Packet Command Mode for more information about this. - - - The filename for the data is computed automatically from the recorded - flight date, TeleMetrum serial number and flight number - information. - - - - Replay Flight - - Select this button and you are prompted to select a flight - record file, either a .telem file recording telemetry data or a - .eeprom file containing flight data saved from the TeleMetrum - flash memory. - - - Once a flight record is selected, the flight monitor interface - is displayed and the flight is re-enacted in real time. Check - the Monitor Flight chapter above to learn how this window operates. - - - - Graph Data - - This section should be written by AJ. - - - - Export Data - - This tool takes the raw data files and makes them available for - external analysis. When you select this button, you are prompted to select a flight - data file (either .eeprom or .telem will do, remember that - .eeprom files contain higher resolution and more continuous - data). Next, a second dialog appears which is used to select - where to write the resulting file. It has a selector to choose - between CSV and KML file formats. - -
- Comma Separated Value Format - - This is a text file containing the data in a form suitable for - import into a spreadsheet or other external data analysis - tool. The first few lines of the file contain the version and - configuration information from the TeleMetrum device, then - there is a single header line which labels all of the - fields. All of these lines start with a '#' character which - most tools can be configured to skip over. - - - The remaining lines of the file contain the data, with 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. - -
-
- Keyhole Markup Language (for Google Earth) - - This is the format used by - Googleearth to provide an overlay within that - application. With this, you can use Googleearth to see the - whole flight path in 3D. - -
- - - Configure TeleMetrum - - Select this button and then select either a TeleMetrum or - TeleDongle Device from the list provided. Selecting a TeleDongle - device will use Packet Comamnd Mode to configure remote - TeleMetrum device. Learn how to use this in the Packet Command - Mode chapter. - - - The first few lines of the dialog provide information about the - connected TeleMetrum 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: - - - - - Save. This writes any changes to the TeleMetrum - configuration parameter block in flash memory. If you don't - press this button, any changes you make will be lost. - - - - - Reset. This resets the dialog to the most recently saved values, - erasing any changes you have made. - - - - - Reboot. This reboots the TeleMetrum device. Use this to - switch from idle to pad mode by rebooting once the rocket is - oriented for flight. - - - - - Close. This closes the dialog. Any unsaved changes will be - lost. - - - - - The rest of the dialog contains the parameters to be configured. - -
- Main Deploy Altitude - - This sets the altitude (above the recorded pad altitude) at - which the 'main' igniter will fire. The drop-down menu shows - some common values, but you can edit the text directly and - choose whatever you like. If the apogee charge fires below - this altitude, then the main charge will fire two seconds - after the apogee charge fires. - -
-
- Apogee Delay - - When flying redundant electronics, it's often important to - ensure that multiple apogee charges don't fire at precisely - the same time as that can overpressurize the apogee deployment - bay and cause a structural failure of the airframe. The Apogee - Delay parameter tells the flight computer to fire the apogee - charge a certain number of seconds after apogee has been - detected. - -
-
- Radio Channel - - This configures which of the 10 radio channels to use for both - telemetry and packet command mode. Note that if you set this - value via packet command mode, you will have to reconfigure - the TeleDongle channel before you will be able to use packet - command mode again. - -
-
- Radio Calibration - - The radios in every Altus Metrum device are calibrated at the - factory to ensure that they transmit and receive on the - specified frequency for each channel. You can adjust that - calibration by changing this value. To change the TeleDongle's - calibration, you must reprogram the unit completely. - -
-
- Callsign - - This sets the callsign included in each telemetry packet. Set this - as needed to conform to your local radio regulations. - -
- - - Configure AltosUI - - This button presents a dialog so that you can configure the AltosUI global settings. - -
- Voice Settings - - AltosUI provides voice annoucements during flight so that you - can keep your eyes on the sky and still get information about - the current flight status. However, sometimes you don't want - to hear them. - - - - Enable—turns all voice announcements on and off - - - - Test Voice—Plays a short message allowing you to verify - that the audio systme is working and the volume settings - are reasonable - - - -
-
- Log Directory - - AltosUI logs all telemetry data and saves all TeleMetrum flash - data to this directory. This directory is also used as the - staring point when selecting data files for display or export. - - - Click on the directory name to bring up a directory choosing - dialog, select a new directory and click 'Select Directory' to - change where AltosUI reads and writes data files. - -
-
- Callsign - - This value is used in command packet mode and is transmitted - in each packet sent from TeleDongle and received from - TeleMetrum. It is not used in telemetry mode as that transmits - packets only from TeleMetrum to TeleDongle. Configure this - with the AltosUI operators callsign as needed to comply with - your local radio regulations. - -
- - - Flash Image - - This reprograms any Altus Metrum device by using a TeleMetrum or - TeleDongle as a programming dongle. Please read the directions - for connecting the programming cable in the main TeleMetrum - manual before reading these instructions. - - - Once you have the programmer and target devices connected, - push the 'Flash Image' button. That will present a dialog box - listing all of the connected devices. Carefully select the - programmer device, not the device to be programmed. - - - Next, select the image to flash to the device. These are named - with the product name and firmware version. The file selector - will start in the directory containing the firmware included - with the AltosUI package. Navigate to the directory containing - the desired firmware if it isn't there. - - - Next, a small dialog containing the device serial number and - RF calibration values should appear. If these values are - incorrect (possibly due to a corrupted image in the device), - enter the correct values here. - - - Finally, a dialog containing a progress bar will follow the - programming process. - - - When programming is complete, the target device will - reboot. Note that if the target device is connected via USB, you - will have to unplug it and then plug it back in for the USB - connection to reset so that you can communicate with the device - again. - - - - Fire Igniter - - - - \ No newline at end of file diff --git a/doc/telemetrum-doc.xsl b/doc/telemetrum-doc.xsl index b7963aec..6be23e7f 100644 --- a/doc/telemetrum-doc.xsl +++ b/doc/telemetrum-doc.xsl @@ -27,6 +27,11 @@ + + 0.3 + 23 November 2010 + New section on AltosUI mostly by Keith + 0.2 18 July 2010 @@ -118,12 +123,12 @@ When you have successfully installed the software suite (either from compiled source code or as the pre-built Debian package) you will have 10 or so executable programs all of which have names beginning - with 'ao-'. + with 'ao-'. ('ao-view' is the lone GUI-based program, the rest are command-line oriented.) You will also have man pages, that give you basic info - on each program. + on each program. You will also get this documentation in two file types in the doc/ -directory, telemetrum-doc.pdf and telemetrum-doc.html. + directory, telemetrum-doc.pdf and telemetrum-doc.html. Finally you will have a couple control files that allow the ao-view GUI-based program to appear in your menu of programs (under the 'Internet' category). @@ -133,7 +138,7 @@ directory, telemetrum-doc.pdf and telemetrum-doc.html. with using USB ports. The first thing you should try after getting both units plugged into to your computer's usb port(s) is to run 'ao-list' from a terminal-window to see what port-device-name each - device has been assigned by the operating system. + device has been assigned by the operating system. You will need this information to access the devices via their respective on-board firmware and data using other command line programs in the AltOS software suite. @@ -158,7 +163,7 @@ directory, telemetrum-doc.pdf and telemetrum-doc.html. Both TeleMetrum and TeleDongle share the concept of a two level command set in their firmware. - The first layer has several single letter commands. Once + The first layer has several single letter commands. Once you are using 'cu' (or 'cutecom') sending (typing) a '?' returns a full list of these commands. The second level are configuration sub-commands accessed @@ -177,7 +182,7 @@ directory, telemetrum-doc.pdf and telemetrum-doc.html. use 'N0CALL' which is cute, but not exactly legal! Spend a few minutes getting comfortable with the units, their firmware, and 'cu' (or possibly 'cutecom'). - For instance, try to send + For instance, try to send (type) a 'c r 2' and verify the channel change by sending a 'c s'. Verify you can connect and disconnect from the units while in your terminal program by sending the escape-disconnect mentioned above. @@ -250,7 +255,7 @@ directory, telemetrum-doc.pdf and telemetrum-doc.html. As for ao-view.... some things are in the menu but don't do anything very useful. The developers have stopped working on ao-view to focus on a new, cross-platform ground station program. So ao-view may or - may not be updated in the future. Mostly you just use + may not be updated in the future. Mostly you just use the Log and Device menus. It has a wonderful display of the incoming flight data and I am sure you will enjoy what it has to say to you once you enable the voice output! @@ -299,611 +304,1171 @@ directory, telemetrum-doc.pdf and telemetrum-doc.html. Live telemetry is written to file(s) whenever 'ao-view' is connected to the TeleDongle. The file area defaults to ~/altos but is easily changed using the menus in 'ao-view'. The files that - are written end in '.telem'. The after-flight + are written end in '.telem'. The after-flight data-dumped files will end in .eeprom and represent continuous data unlike the rf-linked .telem files that are subject to the turnarounds/data-packaging time slots in the half-duplex rf data path. See the above instructions on what and how to save the eeprom stored data after physically retrieving your TeleMetrum. Make sure to save - the on-board data after each flight, as the current firmware will - over-write any previous flight data during a new flight. + the on-board data after each flight, as the current firmware will + over-write any previous flight data during a new flight. + + + + + Specifications + + + + Recording altimeter for model rocketry. + + + + + Supports dual deployment (can fire 2 ejection charges). + + + + + 70cm ham-band transceiver for telemetry downlink. + + + + + Barometric pressure sensor good to 45k feet MSL. + + + + + 1-axis high-g accelerometer for motor characterization, capable of + +/- 50g using default part. + + + + + On-board, integrated GPS receiver with 5hz update rate capability. + + + + + On-board 1 megabyte non-volatile memory for flight data storage. + + + + + USB interface for battery charging, configuration, and data recovery. + + + + + Fully integrated support for LiPo rechargeable batteries. + + + + + Uses LiPo to fire e-matches, support for optional separate pyro + battery if needed. + + + + + 2.75 x 1 inch board designed to fit inside 29mm airframe coupler tube. + + + + + + Handling Precautions + + TeleMetrum is a sophisticated electronic device. When handled gently and + properly installed in an airframe, it will deliver impressive results. + However, like all electronic devices, there are some precautions you + must take. + + + The Lithium Polymer rechargeable batteries used with TeleMetrum have an + extraordinary power density. This is great because we can fly with + much less battery mass than if we used alkaline batteries or previous + generation rechargeable batteries... but if they are punctured + or their leads are allowed to short, they can and will release their + energy very rapidly! + Thus we recommend that you take some care when handling our batteries + and consider giving them some extra protection in your airframe. We + often wrap them in suitable scraps of closed-cell packing foam before + strapping them down, for example. + + + The TeleMetrum barometric sensor is sensitive to sunlight. In normal + mounting situations, it and all of the other surface mount components + are "down" towards whatever the underlying mounting surface is, so + this is not normally a problem. Please consider this, though, when + designing an installation, for example, in a 29mm airframe with a + see-through plastic payload bay. + + + The TeleMetrum barometric sensor sampling port must be able to + "breathe", + both by not being covered by foam or tape or other materials that might + directly block the hole on the top of the sensor, but also by having a + suitable static vent to outside air. + + + As with all other rocketry electronics, TeleMetrum must be protected + from exposure to corrosive motor exhaust and ejection charge gasses. + + + + Hardware Overview + + TeleMetrum is a 1 inch by 2.75 inch circuit board. It was designed to + fit inside coupler for 29mm airframe tubing, but using it in a tube that + small in diameter may require some creativity in mounting and wiring + to succeed! The default 1/4 + wave UHF wire antenna attached to the center of the nose-cone end of + the board is about 7 inches long, and wiring for a power switch and + the e-matches for apogee and main ejection charges depart from the + fin can end of the board. Given all this, an ideal "simple" avionics + bay for TeleMetrum should have at least 10 inches of interior length. + + + A typical TeleMetrum installation using the on-board GPS antenna and + default wire UHF antenna involves attaching only a suitable + Lithium Polymer battery, a single pole switch for power on/off, and + two pairs of wires connecting e-matches for the apogee and main ejection + charges. + + + By default, we use the unregulated output of the LiPo battery directly + to fire ejection charges. This works marvelously with standard + low-current e-matches like the J-Tek from MJG Technologies, and with + Quest Q2G2 igniters. However, if you + want or need to use a separate pyro battery, you can do so by adding + a second 2mm connector to position B2 on the board and cutting the + thick pcb trace connecting the LiPo battery to the pyro circuit between + the two silk screen marks on the surface mount side of the board shown + here [insert photo] + + + We offer two choices of pyro and power switch connector, or you can + choose neither and solder wires directly to the board. All three choices + are reasonable depending on the constraints of your airframe. Our + favorite option when there is sufficient room above the board is to use + the Tyco pin header with polarization and locking. If you choose this + option, you crimp individual wires for the power switch and e-matches + into a mating connector, and installing and removing the TeleMetrum + board from an airframe is as easy as plugging or unplugging two + connectors. If the airframe will not support this much height or if + you want to be able to directly attach e-match leads to the board, we + offer a screw terminal block. This is very similar to what most other + altimeter vendors provide and so may be the most familiar option. + You'll need a very small straight blade screwdriver to connect + and disconnect the board in this case, such as you might find in a + jeweler's screwdriver set. Finally, you can forego both options and + solder wires directly to the board, which may be the best choice for + minimum diameter and/or minimum mass designs. + + + For most airframes, the integrated GPS antenna and wire UHF antenna are + a great combination. However, if you are installing in a carbon-fiber + electronics bay which is opaque to RF signals, you may need to use + off-board external antennas instead. In this case, you can order + TeleMetrum with an SMA connector for the UHF antenna connection, and + you can unplug the integrated GPS antenna and select an appropriate + off-board GPS antenna with cable terminating in a U.FL connector. + + + + System Operation +
+ Firmware Modes + + The AltOS firmware build for TeleMetrum has two fundamental modes, + "idle" and "flight". Which of these modes the firmware operates in + is determined by the orientation of the rocket (well, actually the + board, of course...) at the time power is switched on. If the rocket + is "nose up", then TeleMetrum assumes it's on a rail or rod being + prepared for launch, so the firmware chooses flight mode. However, + if the rocket is more or less horizontal, the firmware instead enters + idle mode. + + + At power on, you will hear three beeps + ("S" in Morse code for startup) and then a pause while + TeleMetrum completes initialization and self tests, and decides which + mode to enter next. + + + In flight or "pad" mode, TeleMetrum turns on the GPS system, + engages the flight + state machine, goes into transmit-only mode on the RF link sending + telemetry, and waits for launch to be detected. Flight mode is + indicated by an audible "di-dah-dah-dit" ("P" for pad) on the + beeper, followed by + beeps indicating the state of the pyrotechnic igniter continuity. + One beep indicates apogee continuity, two beeps indicate + main continuity, three beeps indicate both apogee and main continuity, + and one longer "brap" sound indicates no continuity. For a dual + deploy flight, make sure you're getting three beeps before launching! + For apogee-only or motor eject flights, do what makes sense. + + + In idle mode, you will hear an audible "di-dit" ("I" for idle), and + the normal flight state machine is disengaged, thus + no ejection charges will fire. TeleMetrum also listens on the RF + link when in idle mode for packet mode requests sent from TeleDongle. + Commands can be issued to a TeleMetrum in idle mode over either + USB or the RF link equivalently. + Idle mode is useful for configuring TeleMetrum, for extracting data + from the on-board storage chip after flight, and for ground testing + pyro charges. + + + One "neat trick" of particular value when TeleMetrum is used with very + large airframes, is that you can power the board up while the rocket + is horizontal, such that it comes up in idle mode. Then you can + raise the airframe to launch position, use a TeleDongle to open + a packet connection, and issue a 'reset' command which will cause + TeleMetrum to reboot, realize it's now nose-up, and thus choose + flight mode. This is much safer than standing on the top step of a + rickety step-ladder or hanging off the side of a launch tower with + a screw-driver trying to turn on your avionics before installing + igniters! + +
+
+ GPS + + TeleMetrum includes a complete GPS receiver. See a later section for + a brief explanation of how GPS works that will help you understand + the information in the telemetry stream. The bottom line is that + the TeleMetrum GPS receiver needs to lock onto at least four + satellites to obtain a solid 3 dimensional position fix and know + what time it is! + + + TeleMetrum provides backup power to the GPS chip any time a LiPo + battery is connected. This allows the receiver to "warm start" on + the launch rail much faster than if every power-on were a "cold start" + for the GPS receiver. In typical operations, powering up TeleMetrum + on the flight line in idle mode while performing final airframe + preparation will be sufficient to allow the GPS receiver to cold + start and acquire lock. Then the board can be powered down during + RSO review and installation on a launch rod or rail. When the board + is turned back on, the GPS system should lock very quickly, typically + long before igniter installation and return to the flight line are + complete. + +
+
+ Ground Testing + + An important aspect of preparing a rocket using electronic deployment + for flight is ground testing the recovery system. Thanks + to the bi-directional RF link central to the Altus Metrum system, + this can be accomplished in a TeleMetrum-equipped rocket without as + much work as you may be accustomed to with other systems. It can + even be fun! + + + Just prep the rocket for flight, then power up TeleMetrum while the + airframe is horizontal. This will cause the firmware to go into + "idle" mode, in which the normal flight state machine is disabled and + charges will not fire without manual command. Then, establish an + RF packet connection from a TeleDongle-equipped computer using the + P command from a safe distance. You can now command TeleMetrum to + fire the apogee or main charges to complete your testing. + + + In order to reduce the chance of accidental firing of pyrotechnic + charges, the command to fire a charge is intentionally somewhat + difficult to type, and the built-in help is slightly cryptic to + prevent accidental echoing of characters from the help text back at + the board from firing a charge. The command to fire the apogee + drogue charge is 'i DoIt drogue' and the command to fire the main + charge is 'i DoIt main'. + +
+
+ Radio Link + + The chip our boards are based on incorporates an RF transceiver, but + it's not a full duplex system... each end can only be transmitting or + receiving at any given moment. So we had to decide how to manage the + link. + + + By design, TeleMetrum firmware listens for an RF connection when + it's in "idle mode" (turned on while the rocket is horizontal), which + allows us to use the RF link to configure the rocket, do things like + ejection tests, and extract data after a flight without having to + crack open the airframe. However, when the board is in "flight + mode" (turned on when the rocket is vertical) the TeleMetrum only + transmits and doesn't listen at all. That's because we want to put + ultimate priority on event detection and getting telemetry out of + the rocket and out over + the RF link in case the rocket crashes and we aren't able to extract + data later... + + + We don't use a 'normal packet radio' mode because they're just too + inefficient. The GFSK modulation we use is just FSK with the + baseband pulses passed through a + Gaussian filter before they go into the modulator to limit the + transmitted bandwidth. When combined with the hardware forward error + correction support in the cc1111 chip, this allows us to have a very + robust 38.4 kilobit data link with only 10 milliwatts of transmit power, + a whip antenna in the rocket, and a hand-held Yagi on the ground. We've + had flights to above 21k feet AGL with good reception, and calculations + suggest we should be good to well over 40k feet AGL with a 5-element yagi on + the ground. We hope to fly boards to higher altitudes soon, and would + of course appreciate customer feedback on performance in higher + altitude flights! + +
+
+ Configurable Parameters + + Configuring a TeleMetrum board for flight is very simple. Because we + have both acceleration and pressure sensors, there is no need to set + a "mach delay", for example. The few configurable parameters can all + be set using a simple terminal program over the USB port or RF link + via TeleDongle. + +
+ Radio Channel + + Our firmware supports 10 channels. The default channel 0 corresponds + to a center frequency of 434.550 Mhz, and channels are spaced every + 100 khz. Thus, channel 1 is 434.650 Mhz, and channel 9 is 435.550 Mhz. + At any given launch, we highly recommend coordinating who will use + each channel and when to avoid interference. And of course, both + TeleMetrum and TeleDongle must be configured to the same channel to + successfully communicate with each other. + + + To set the radio channel, use the 'c r' command, like 'c r 3' to set + channel 3. + As with all 'c' sub-commands, follow this with a 'c w' to write the + change to the parameter block in the on-board DataFlash chip on + your TeleMetrum board if you want the change to stay in place across reboots. + +
+
+ Apogee Delay + + Apogee delay is the number of seconds after TeleMetrum detects flight + apogee that the drogue charge should be fired. In most cases, this + should be left at the default of 0. However, if you are flying + redundant electronics such as for an L3 certification, you may wish + to set one of your altimeters to a positive delay so that both + primary and backup pyrotechnic charges do not fire simultaneously. + + + To set the apogee delay, use the [FIXME] command. + As with all 'c' sub-commands, follow this with a 'c w' to write the + change to the parameter block in the on-board DataFlash chip. + + + Please note that the TeleMetrum apogee detection algorithm always + fires a fraction of a second *after* apogee. If you are also flying + an altimeter like the PerfectFlite MAWD, which only supports selecting + 0 or 1 seconds of apogee delay, you may wish to set the MAWD to 0 + seconds delay and set the TeleMetrum to fire your backup 2 or 3 + seconds later to avoid any chance of both charges firing + simultaneously. We've flown several airframes this way quite happily, + including Keith's successful L3 cert.
- - - Specifications +
+ Main Deployment Altitude + + By default, TeleMetrum will fire the main deployment charge at an + elevation of 250 meters (about 820 feet) above ground. We think this + is a good elevation for most airframes, but feel free to change this + to suit. In particular, if you are flying two altimeters, you may + wish to set the + deployment elevation for the backup altimeter to be something lower + than the primary so that both pyrotechnic charges don't fire + simultaneously. + + + To set the main deployment altitude, use the [FIXME] command. + As with all 'c' sub-commands, follow this with a 'c w' to write the + change to the parameter block in the on-board DataFlash chip. + +
+
+
+ Calibration + + There are only two calibrations required for a TeleMetrum board, and + only one for TeleDongle. + +
+ Radio Frequency + + The radio frequency is synthesized from a clock based on the 48 Mhz + crystal on the board. The actual frequency of this oscillator must be + measured to generate a calibration constant. While our GFSK modulation + bandwidth is wide enough to allow boards to communicate even when + their oscillators are not on exactly the same frequency, performance + is best when they are closely matched. + Radio frequency calibration requires a calibrated frequency counter. + Fortunately, once set, the variation in frequency due to aging and + temperature changes is small enough that re-calibration by customers + should generally not be required. + + + To calibrate the radio frequency, connect the UHF antenna port to a + frequency counter, set the board to channel 0, and use the 'C' + command to generate a CW carrier. Wait for the transmitter temperature + to stabilize and the frequency to settle down. + Then, divide 434.550 Mhz by the + measured frequency and multiply by the current radio cal value show + in the 'c s' command. For an unprogrammed board, the default value + is 1186611. Take the resulting integer and program it using the 'c f' + command. Testing with the 'C' command again should show a carrier + within a few tens of Hertz of the intended frequency. + As with all 'c' sub-commands, follow this with a 'c w' to write the + change to the parameter block in the on-board DataFlash chip. + +
+
+ Accelerometer + + The accelerometer we use has its own 5 volt power supply and + the output must be passed through a resistive voltage divider to match + the input of our 3.3 volt ADC. This means that unlike the barometric + sensor, the output of the acceleration sensor is not ratiometric to + the ADC converter, and calibration is required. We also support the + use of any of several accelerometers from a Freescale family that + includes at least +/- 40g, 50g, 100g, and 200g parts. Using gravity, + a simple 2-point calibration yields acceptable results capturing both + the different sensitivities and ranges of the different accelerometer + parts and any variation in power supply voltages or resistor values + in the divider network. + + + To calibrate the acceleration sensor, use the 'c a 0' command. You + will be prompted to orient the board vertically with the UHF antenna + up and press a key, then to orient the board vertically with the + UHF antenna down and press a key. + As with all 'c' sub-commands, follow this with a 'c w' to write the + change to the parameter block in the on-board DataFlash chip. + + + The +1g and -1g calibration points are included in each telemetry + frame and are part of the header extracted by ao-dumplog after flight. + Note that we always store and return raw ADC samples for each + sensor... nothing is permanently "lost" or "damaged" if the + calibration is poor. + +
+
+ + + + AltosUI + + The AltosUI program provides a graphical user interface for + interacting with the Altus Metrum product family, including + TeleMetrum and TeleDongle. AltosUI can monitor telemetry data, + configure TeleMetrum and TeleDongle devices and many other + tasks. The primary interface window provides a selection of + buttons, one for each major activity in the system. This manual + is split into chapters, each of which documents one of the tasks + provided from the top-level toolbar. + +
+ Packet Command Mode + Controlling TeleMetrum Over The Radio Link + + One of the unique features of the Altos Metrum environment is + the ability to create a two way command link between TeleDongle + and TeleMetrum using the digital radio transceivers built into + each device. This allows you to interact with TeleMetrum from + afar, as if it were directly connected to the computer. + + + Any operation which can be performed with TeleMetrum + can either be done with TeleMetrum directly connected to + the computer via the USB cable, or through the packet + link. Simply select the appropriate TeleDongle device when + the list of devices is presented and AltosUI will use packet + command mode. + - Recording altimeter for model rocketry. + Save Flight Data—Recover flight data from the rocket without + opening it up. - Supports dual deployment (can fire 2 ejection charges). + Configure TeleMetrum—Reset apogee delays or main deploy + heights to respond to changing launch conditions. You can + also 'reboot' the TeleMetrum device. Use this to remotely + enable the flight computer by turning TeleMetrum on while + horizontal, then once the airframe is oriented for launch, + you can reboot TeleMetrum and have it restart in pad mode + without having to climb the scary ladder. - 70cm ham-band transceiver for telemetry downlink. + Fire Igniters—Test your deployment charges without snaking + wires out through holes in the airframe. Simply assembly the + rocket as if for flight with the apogee and main charges + loaded, then remotely command TeleMetrum to fire the + igniters. + + + Packet command mode uses the same RF channels as telemetry + mode. Configure the desired TeleDongle channel using the + flight monitor window channel selector and then close that + window before performing the desired operation. + + + TeleMetrum only enables packet command mode in 'idle' mode, so + make sure you have TeleMetrum lying horizontally when you turn + it on. Otherwise, TeleMetrum will start in 'pad' mode ready for + flight and will not be listening for command packets from TeleDongle. + + + When packet command mode is enabled, you can monitor the link + by watching the lights on the TeleDongle and TeleMetrum + devices. The red LED will flash each time TeleDongle or + TeleMetrum transmit a packet while the green LED will light up + on TeleDongle while it is waiting to receive a packet from + TeleMetrum. + +
+
+ Monitor Flight + Receive, Record and Display Telemetry Data + + Selecting this item brings up a dialog box listing all of the + connected TeleDongle devices. When you choose one of these, + AltosUI will create a window to display telemetry data as + received by the selected TeleDongle device. + + + 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 channel being monitored by the TeleDongle device is + displayed at the top of the window. You can configure the + channel by clicking on the channel box and selecting the desired + channel. AltosUI remembers the last channel selected for each + TeleDongle and selects that automatically the next time you use + that device. + + + Below the TeleDongle channel selector, the window contains a few + significant pieces of information about the TeleMetrum providing + the telemetry data stream: + + - - Barometric pressure sensor good to 45k feet MSL. - + The TeleMetrum callsign - - 1-axis high-g accelerometer for motor characterization, capable of - +/- 50g using default part. + The TeleMetrum serial number + + + The flight number. Each TeleMetrum remembers how many + times it has flown. - On-board, integrated GPS receiver with 5hz update rate capability. + The rocket flight state. Each flight passes through several + states including Pad, Boost, Fast, Coast, Drogue, Main and + Landed. - On-board 1 megabyte non-volatile memory for flight data storage. + The Received Signal Strength Indicator value. This lets + you know how strong a signal TeleDongle is receiving. The + radio inside TeleDongle operates down to about -99dBm; + weaker signals may not be receiveable. The packet link uses + error correction and detection techniques which prevent + incorrect data from being reported. + + + Finally, the largest portion of the window contains a set of + tabs, each of which contain some information about the rocket. + They're arranged in 'flight order' so that as the flight + progresses, the selected tab 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 contains all of + the telemetry data in one place. + +
+ Launch Pad + + The 'Launch Pad' tab shows information used to decide when the + rocket is ready for flight. The first elements include red/green + indicators, if any of these is red, you'll want to evaluate + whether the rocket is ready to launch: + + + + Battery Voltage. This indicates whether the LiPo battery + powering the TeleMetrum has sufficient charge to last for + the duration of the flight. A value of more than + 3.7V is required for a 'GO' status. + + + + + Apogee Igniter Voltage. This indicates whether the apogee + igniter has continuity. If the igniter has a low + resistance, then the voltage measured here will be close + to the LiPo battery voltage. A value greater than 3.2V is + required for a 'GO' status. + + + + + Main Igniter Voltage. This indicates whether the main + igniter has continuity. If the igniter has a low + resistance, then the voltage measured here will be close + to the LiPo battery voltage. A value greater than 3.2V is + required for a 'GO' status. + + + + + GPS Locked. This indicates whether the GPS receiver is + currently able to compute position information. GPS requires + at least 4 satellites to compute an accurate position. + + + + + GPS Ready. This indicates whether GPS has reported at least + 10 consecutive positions without losing lock. This ensures + that the 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. + + +
+
+ Ascent + + 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 and acceleration are shown along with the + maxium values for each of them. This allows you to quickly + answer the most commonly asked questions you'll hear during + flight. + + + The current latitude and longitude reported by the GPS are + also shown. Note that under high acceleration, these values + 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. + +
+
+ Descent + + Once the rocket has reached apogee and (we hope) activated the + apogee charge, attention switches to tracking the rocket on + the way back to the ground, and for dual-deploy flights, + waiting for the main charge to fire. + + + To monitor whether the apogee charge operated correctly, the + current descent rate is reported along with the current + height. Good descent rates generally range from 15-30m/s. + + + To help locate the rocket in the sky, use the elevation and + bearing information to figure out where to look. Elevation is + in degrees above the horizon. Bearing is reported in degrees + relative to true north. Range can help figure out how big the + rocket will appear. Note that all of these values are relative + to the pad location. If the elevation is near 90°, the rocket + is over the pad, not over you. + + + Finally, the igniter voltages are reported in this tab as + well, both to monitor the main charge as well as to see what + the status of the apogee charge is. + +
+
+ Landed + + Once the rocket is on the ground, attention switches to + recovery. While the radio signal is generally lost once the + rocket is on the ground, the last reported GPS position is + generally within a short distance of the actual landing location. + + + The last reported GPS position is reported both by + latitude and longitude as well as a bearing and distance from + the launch pad. The distance should give you a good idea of + whether you'll want to walk or hitch a ride. Take the reported + latitude and longitude and enter them into your handheld GPS + unit and have that compute a track to the landing location. + + + Finally, the maximum height, speed and acceleration reported + during the flight are displayed for your admiring observers. + +
+
+
+ Save Flight Data + + TeleMetrum records flight data to its internal flash memory. + This data is recorded at a much higher rate than the telemetry + system can handle, and is not subject to radio drop-outs. As + such, it provides a more complete and precise record of the + flight. The 'Save Flight Data' button allows you to read the + flash memory and write it to disk. + + + Clicking on the 'Save Flight Data' button brings up a list of + connected TeleMetrum and TeleDongle devices. If you select a + TeleMetrum device, the flight data will be downloaded from that + device directly. If you select a TeleDongle device, flight data + will be downloaded from a TeleMetrum device connected via the + packet command link to the specified TeleDongle. See the chapter + on Packet Command Mode for more information about this. + + + The filename for the data is computed automatically from the recorded + flight date, TeleMetrum serial number and flight number + information. + +
+
+ Replay Flight + + Select this button and you are prompted to select a flight + record file, either a .telem file recording telemetry data or a + .eeprom file containing flight data saved from the TeleMetrum + flash memory. + + + Once a flight record is selected, the flight monitor interface + is displayed and the flight is re-enacted in real time. Check + the Monitor Flight chapter above to learn how this window operates. + +
+
+ Graph Data + + This section should be written by AJ. + +
+
+ Export Data + + This tool takes the raw data files and makes them available for + external analysis. When you select this button, you are prompted to select a flight + data file (either .eeprom or .telem will do, remember that + .eeprom files contain higher resolution and more continuous + data). Next, a second dialog appears which is used to select + where to write the resulting file. It has a selector to choose + between CSV and KML file formats. + +
+ Comma Separated Value Format + + This is a text file containing the data in a form suitable for + import into a spreadsheet or other external data analysis + tool. The first few lines of the file contain the version and + configuration information from the TeleMetrum device, then + there is a single header line which labels all of the + fields. All of these lines start with a '#' character which + most tools can be configured to skip over. + + + The remaining lines of the file contain the data, with 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. + +
+
+ Keyhole Markup Language (for Google Earth) + + This is the format used by + Googleearth to provide an overlay within that + application. With this, you can use Googleearth to see the + whole flight path in 3D. + +
+
+
+ Configure TeleMetrum + + Select this button and then select either a TeleMetrum or + TeleDongle Device from the list provided. Selecting a TeleDongle + device will use Packet Comamnd Mode to configure remote + TeleMetrum device. Learn how to use this in the Packet Command + Mode chapter. + + + The first few lines of the dialog provide information about the + connected TeleMetrum 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: + + - USB interface for battery charging, configuration, and data recovery. + Save. This writes any changes to the TeleMetrum + configuration parameter block in flash memory. If you don't + press this button, any changes you make will be lost. - Fully integrated support for LiPo rechargeable batteries. + Reset. This resets the dialog to the most recently saved values, + erasing any changes you have made. - Uses LiPo to fire e-matches, support for optional separate pyro - battery if needed. + Reboot. This reboots the TeleMetrum device. Use this to + switch from idle to pad mode by rebooting once the rocket is + oriented for flight. - 2.75 x 1 inch board designed to fit inside 29mm airframe coupler tube. + Close. This closes the dialog. Any unsaved changes will be + lost. - - - Handling Precautions - - TeleMetrum is a sophisticated electronic device. When handled gently and - properly installed in an airframe, it will deliver impressive results. - However, like all electronic devices, there are some precautions you - must take. - - - The Lithium Polymer rechargeable batteries used with TeleMetrum have an - extraordinary power density. This is great because we can fly with - much less battery mass than if we used alkaline batteries or previous - generation rechargeable batteries... but if they are punctured - or their leads are allowed to short, they can and will release their - energy very rapidly! - Thus we recommend that you take some care when handling our batteries - and consider giving them some extra protection in your airframe. We - often wrap them in suitable scraps of closed-cell packing foam before - strapping them down, for example. - - - The TeleMetrum barometric sensor is sensitive to sunlight. In normal - mounting situations, it and all of the other surface mount components - are "down" towards whatever the underlying mounting surface is, so - this is not normally a problem. Please consider this, though, when - designing an installation, for example, in a 29mm airframe with a - see-through plastic payload bay. - - - The TeleMetrum barometric sensor sampling port must be able to - "breathe", - both by not being covered by foam or tape or other materials that might - directly block the hole on the top of the sensor, but also by having a - suitable static vent to outside air. - - - As with all other rocketry electronics, TeleMetrum must be protected - from exposure to corrosive motor exhaust and ejection charge gasses. - - - - Hardware Overview - - TeleMetrum is a 1 inch by 2.75 inch circuit board. It was designed to - fit inside coupler for 29mm airframe tubing, but using it in a tube that - small in diameter may require some creativity in mounting and wiring - to succeed! The default 1/4 - wave UHF wire antenna attached to the center of the nose-cone end of - the board is about 7 inches long, and wiring for a power switch and - the e-matches for apogee and main ejection charges depart from the - fin can end of the board. Given all this, an ideal "simple" avionics - bay for TeleMetrum should have at least 10 inches of interior length. - - - A typical TeleMetrum installation using the on-board GPS antenna and - default wire UHF antenna involves attaching only a suitable - Lithium Polymer battery, a single pole switch for power on/off, and - two pairs of wires connecting e-matches for the apogee and main ejection - charges. - - - By default, we use the unregulated output of the LiPo battery directly - to fire ejection charges. This works marvelously with standard - low-current e-matches like the J-Tek from MJG Technologies, and with - Quest Q2G2 igniters. However, if you - want or need to use a separate pyro battery, you can do so by adding - a second 2mm connector to position B2 on the board and cutting the - thick pcb trace connecting the LiPo battery to the pyro circuit between - the two silk screen marks on the surface mount side of the board shown - here [insert photo] - - - We offer two choices of pyro and power switch connector, or you can - choose neither and solder wires directly to the board. All three choices - are reasonable depending on the constraints of your airframe. Our - favorite option when there is sufficient room above the board is to use - the Tyco pin header with polarization and locking. If you choose this - option, you crimp individual wires for the power switch and e-matches - into a mating connector, and installing and removing the TeleMetrum - board from an airframe is as easy as plugging or unplugging two - connectors. If the airframe will not support this much height or if - you want to be able to directly attach e-match leads to the board, we - offer a screw terminal block. This is very similar to what most other - altimeter vendors provide and so may be the most familiar option. - You'll need a very small straight blade screwdriver to connect - and disconnect the board in this case, such as you might find in a - jeweler's screwdriver set. Finally, you can forego both options and - solder wires directly to the board, which may be the best choice for - minimum diameter and/or minimum mass designs. - - - For most airframes, the integrated GPS antenna and wire UHF antenna are - a great combination. However, if you are installing in a carbon-fiber - electronics bay which is opaque to RF signals, you may need to use - off-board external antennas instead. In this case, you can order - TeleMetrum with an SMA connector for the UHF antenna connection, and - you can unplug the integrated GPS antenna and select an appropriate - off-board GPS antenna with cable terminating in a U.FL connector. - - - - Operation + + The rest of the dialog contains the parameters to be configured. +
- Firmware Modes - - The AltOS firmware build for TeleMetrum has two fundamental modes, - "idle" and "flight". Which of these modes the firmware operates in - is determined by the orientation of the rocket (well, actually the - board, of course...) at the time power is switched on. If the rocket - is "nose up", then TeleMetrum assumes it's on a rail or rod being - prepared for launch, so the firmware chooses flight mode. However, - if the rocket is more or less horizontal, the firmware instead enters - idle mode. - - - At power on, you will hear three beeps - ("S" in Morse code for startup) and then a pause while - TeleMetrum completes initialization and self tests, and decides which - mode to enter next. - - - In flight or "pad" mode, TeleMetrum turns on the GPS system, - engages the flight - state machine, goes into transmit-only mode on the RF link sending - telemetry, and waits for launch to be detected. Flight mode is - indicated by an audible "di-dah-dah-dit" ("P" for pad) on the - beeper, followed by - beeps indicating the state of the pyrotechnic igniter continuity. - One beep indicates apogee continuity, two beeps indicate - main continuity, three beeps indicate both apogee and main continuity, - and one longer "brap" sound indicates no continuity. For a dual - deploy flight, make sure you're getting three beeps before launching! - For apogee-only or motor eject flights, do what makes sense. - - - In idle mode, you will hear an audible "di-dit" ("I" for idle), and - the normal flight state machine is disengaged, thus - no ejection charges will fire. TeleMetrum also listens on the RF - link when in idle mode for packet mode requests sent from TeleDongle. - Commands can be issued to a TeleMetrum in idle mode over either - USB or the RF link equivalently. - Idle mode is useful for configuring TeleMetrum, for extracting data - from the on-board storage chip after flight, and for ground testing - pyro charges. - - - One "neat trick" of particular value when TeleMetrum is used with very - large airframes, is that you can power the board up while the rocket - is horizontal, such that it comes up in idle mode. Then you can - raise the airframe to launch position, use a TeleDongle to open - a packet connection, and issue a 'reset' command which will cause - TeleMetrum to reboot, realize it's now nose-up, and thus choose - flight mode. This is much safer than standing on the top step of a - rickety step-ladder or hanging off the side of a launch tower with - a screw-driver trying to turn on your avionics before installing - igniters! + Main Deploy Altitude + + This sets the altitude (above the recorded pad altitude) at + which the 'main' igniter will fire. The drop-down menu shows + some common values, but you can edit the text directly and + choose whatever you like. If the apogee charge fires below + this altitude, then the main charge will fire two seconds + after the apogee charge fires.
- GPS - - TeleMetrum includes a complete GPS receiver. See a later section for - a brief explanation of how GPS works that will help you understand - the information in the telemetry stream. The bottom line is that - the TeleMetrum GPS receiver needs to lock onto at least four - satellites to obtain a solid 3 dimensional position fix and know - what time it is! - - - TeleMetrum provides backup power to the GPS chip any time a LiPo - battery is connected. This allows the receiver to "warm start" on - the launch rail much faster than if every power-on were a "cold start" - for the GPS receiver. In typical operations, powering up TeleMetrum - on the flight line in idle mode while performing final airframe - preparation will be sufficient to allow the GPS receiver to cold - start and acquire lock. Then the board can be powered down during - RSO review and installation on a launch rod or rail. When the board - is turned back on, the GPS system should lock very quickly, typically - long before igniter installation and return to the flight line are - complete. + Apogee Delay + + When flying redundant electronics, it's often important to + ensure that multiple apogee charges don't fire at precisely + the same time as that can overpressurize the apogee deployment + bay and cause a structural failure of the airframe. The Apogee + Delay parameter tells the flight computer to fire the apogee + charge a certain number of seconds after apogee has been + detected.
- Ground Testing + Radio Channel - An important aspect of preparing a rocket using electronic deployment - for flight is ground testing the recovery system. Thanks - to the bi-directional RF link central to the Altus Metrum system, - this can be accomplished in a TeleMetrum-equipped rocket without as - much work as you may be accustomed to with other systems. It can - even be fun! + This configures which of the 10 radio channels to use for both + telemetry and packet command mode. Note that if you set this + value via packet command mode, you will have to reconfigure + the TeleDongle channel before you will be able to use packet + command mode again. +
+
+ Radio Calibration - Just prep the rocket for flight, then power up TeleMetrum while the - airframe is horizontal. This will cause the firmware to go into - "idle" mode, in which the normal flight state machine is disabled and - charges will not fire without manual command. Then, establish an - RF packet connection from a TeleDongle-equipped computer using the - P command from a safe distance. You can now command TeleMetrum to - fire the apogee or main charges to complete your testing. + The radios in every Altus Metrum device are calibrated at the + factory to ensure that they transmit and receive on the + specified frequency for each channel. You can adjust that + calibration by changing this value. To change the TeleDongle's + calibration, you must reprogram the unit completely. +
+
+ Callsign - In order to reduce the chance of accidental firing of pyrotechnic - charges, the command to fire a charge is intentionally somewhat - difficult to type, and the built-in help is slightly cryptic to - prevent accidental echoing of characters from the help text back at - the board from firing a charge. The command to fire the apogee - drogue charge is 'i DoIt drogue' and the command to fire the main - charge is 'i DoIt main'. + This sets the callsign included in each telemetry packet. Set this + as needed to conform to your local radio regulations.
+
+
+ Configure AltosUI + + This button presents a dialog so that you can configure the AltosUI global settings. +
- Radio Link - - The chip our boards are based on incorporates an RF transceiver, but - it's not a full duplex system... each end can only be transmitting or - receiving at any given moment. So we had to decide how to manage the - link. - - - By design, TeleMetrum firmware listens for an RF connection when - it's in "idle mode" (turned on while the rocket is horizontal), which - allows us to use the RF link to configure the rocket, do things like - ejection tests, and extract data after a flight without having to - crack open the airframe. However, when the board is in "flight - mode" (turned on when the rocket is vertical) the TeleMetrum only - transmits and doesn't listen at all. That's because we want to put - ultimate priority on event detection and getting telemetry out of - the rocket and out over - the RF link in case the rocket crashes and we aren't able to extract - data later... - - - We don't use a 'normal packet radio' mode because they're just too - inefficient. The GFSK modulation we use is just FSK with the - baseband pulses passed through a - Gaussian filter before they go into the modulator to limit the - transmitted bandwidth. When combined with the hardware forward error - correction support in the cc1111 chip, this allows us to have a very - robust 38.4 kilobit data link with only 10 milliwatts of transmit power, - a whip antenna in the rocket, and a hand-held Yagi on the ground. We've - had flights to above 21k feet AGL with good reception, and calculations - suggest we should be good to well over 40k feet AGL with a 5-element yagi on - the ground. We hope to fly boards to higher altitudes soon, and would - of course appreciate customer feedback on performance in higher - altitude flights! + Voice Settings + + AltosUI provides voice annoucements during flight so that you + can keep your eyes on the sky and still get information about + the current flight status. However, sometimes you don't want + to hear them. + + + Enable—turns all voice announcements on and off + + + + Test Voice—Plays a short message allowing you to verify + that the audio systme is working and the volume settings + are reasonable + + +
- Configurable Parameters + Log Directory - Configuring a TeleMetrum board for flight is very simple. Because we - have both acceleration and pressure sensors, there is no need to set - a "mach delay", for example. The few configurable parameters can all - be set using a simple terminal program over the USB port or RF link - via TeleDongle. + AltosUI logs all telemetry data and saves all TeleMetrum flash + data to this directory. This directory is also used as the + staring point when selecting data files for display or export. + + + Click on the directory name to bring up a directory choosing + dialog, select a new directory and click 'Select Directory' to + change where AltosUI reads and writes data files. -
- Radio Channel - - Our firmware supports 10 channels. The default channel 0 corresponds - to a center frequency of 434.550 Mhz, and channels are spaced every - 100 khz. Thus, channel 1 is 434.650 Mhz, and channel 9 is 435.550 Mhz. - At any given launch, we highly recommend coordinating who will use - each channel and when to avoid interference. And of course, both - TeleMetrum and TeleDongle must be configured to the same channel to - successfully communicate with each other. - - - To set the radio channel, use the 'c r' command, like 'c r 3' to set - channel 3. - As with all 'c' sub-commands, follow this with a 'c w' to write the - change to the parameter block in the on-board DataFlash chip on - your TeleMetrum board if you want the change to stay in place across reboots. - -
-
- Apogee Delay - - Apogee delay is the number of seconds after TeleMetrum detects flight - apogee that the drogue charge should be fired. In most cases, this - should be left at the default of 0. However, if you are flying - redundant electronics such as for an L3 certification, you may wish - to set one of your altimeters to a positive delay so that both - primary and backup pyrotechnic charges do not fire simultaneously. - - - To set the apogee delay, use the [FIXME] command. - As with all 'c' sub-commands, follow this with a 'c w' to write the - change to the parameter block in the on-board DataFlash chip. - - - Please note that the TeleMetrum apogee detection algorithm always - fires a fraction of a second *after* apogee. If you are also flying - an altimeter like the PerfectFlite MAWD, which only supports selecting - 0 or 1 seconds of apogee delay, you may wish to set the MAWD to 0 - seconds delay and set the TeleMetrum to fire your backup 2 or 3 - seconds later to avoid any chance of both charges firing - simultaneously. We've flown several airframes this way quite happily, - including Keith's successful L3 cert. - -
-
- Main Deployment Altitude - - By default, TeleMetrum will fire the main deployment charge at an - elevation of 250 meters (about 820 feet) above ground. We think this - is a good elevation for most airframes, but feel free to change this - to suit. In particular, if you are flying two altimeters, you may - wish to set the - deployment elevation for the backup altimeter to be something lower - than the primary so that both pyrotechnic charges don't fire - simultaneously. - - - To set the main deployment altitude, use the [FIXME] command. - As with all 'c' sub-commands, follow this with a 'c w' to write the - change to the parameter block in the on-board DataFlash chip. - -
- Calibration + Callsign - There are only two calibrations required for a TeleMetrum board, and - only one for TeleDongle. + This value is used in command packet mode and is transmitted + in each packet sent from TeleDongle and received from + TeleMetrum. It is not used in telemetry mode as that transmits + packets only from TeleMetrum to TeleDongle. Configure this + with the AltosUI operators callsign as needed to comply with + your local radio regulations. -
- Radio Frequency - - The radio frequency is synthesized from a clock based on the 48 Mhz - crystal on the board. The actual frequency of this oscillator must be - measured to generate a calibration constant. While our GFSK modulation - bandwidth is wide enough to allow boards to communicate even when - their oscillators are not on exactly the same frequency, performance - is best when they are closely matched. - Radio frequency calibration requires a calibrated frequency counter. - Fortunately, once set, the variation in frequency due to aging and - temperature changes is small enough that re-calibration by customers - should generally not be required. - - - To calibrate the radio frequency, connect the UHF antenna port to a - frequency counter, set the board to channel 0, and use the 'C' - command to generate a CW carrier. Wait for the transmitter temperature - to stabilize and the frequency to settle down. - Then, divide 434.550 Mhz by the - measured frequency and multiply by the current radio cal value show - in the 'c s' command. For an unprogrammed board, the default value - is 1186611. Take the resulting integer and program it using the 'c f' - command. Testing with the 'C' command again should show a carrier - within a few tens of Hertz of the intended frequency. - As with all 'c' sub-commands, follow this with a 'c w' to write the - change to the parameter block in the on-board DataFlash chip. - -
-
- Accelerometer - - The accelerometer we use has its own 5 volt power supply and - the output must be passed through a resistive voltage divider to match - the input of our 3.3 volt ADC. This means that unlike the barometric - sensor, the output of the acceleration sensor is not ratiometric to - the ADC converter, and calibration is required. We also support the - use of any of several accelerometers from a Freescale family that - includes at least +/- 40g, 50g, 100g, and 200g parts. Using gravity, - a simple 2-point calibration yields acceptable results capturing both - the different sensitivities and ranges of the different accelerometer - parts and any variation in power supply voltages or resistor values - in the divider network. - - - To calibrate the acceleration sensor, use the 'c a 0' command. You - will be prompted to orient the board vertically with the UHF antenna - up and press a key, then to orient the board vertically with the - UHF antenna down and press a key. - As with all 'c' sub-commands, follow this with a 'c w' to write the - change to the parameter block in the on-board DataFlash chip. - - - The +1g and -1g calibration points are included in each telemetry - frame and are part of the header extracted by ao-dumplog after flight. - Note that we always store and return raw ADC samples for each - sensor... nothing is permanently "lost" or "damaged" if the - calibration is poor. - -
- - - Using Altus Metrum Products +
+
+ Flash Image + + This reprograms any Altus Metrum device by using a TeleMetrum or + TeleDongle as a programming dongle. Please read the directions + for connecting the programming cable in the main TeleMetrum + manual before reading these instructions. + + + Once you have the programmer and target devices connected, + push the 'Flash Image' button. That will present a dialog box + listing all of the connected devices. Carefully select the + programmer device, not the device to be programmed. + + + Next, select the image to flash to the device. These are named + with the product name and firmware version. The file selector + will start in the directory containing the firmware included + with the AltosUI package. Navigate to the directory containing + the desired firmware if it isn't there. + + + Next, a small dialog containing the device serial number and + RF calibration values should appear. If these values are + incorrect (possibly due to a corrupted image in the device), + enter the correct values here. + + + Finally, a dialog containing a progress bar will follow the + programming process. + + + When programming is complete, the target device will + reboot. Note that if the target device is connected via USB, you + will have to unplug it and then plug it back in for the USB + connection to reset so that you can communicate with the device + again. + +
+
+ Fire Igniter + + +
+ + + Using Altus Metrum Products +
+ Being Legal + + First off, in the US, you need an [amateur radio license](../Radio) or + other authorization to legally operate the radio transmitters that are part + of our products. +
- Being Legal + In the Rocket - First off, in the US, you need an [amateur radio license](../Radio) or - other authorization to legally operate the radio transmitters that are part - of our products. + In the rocket itself, you just need a [TeleMetrum](../TeleMetrum) board and + a LiPo rechargeable battery. An 860mAh battery weighs less than a 9V + alkaline battery, and will run a [TeleMetrum](../TeleMetrum) for hours. + + + By default, we ship TeleMetrum with a simple wire antenna. If your + electronics bay or the airframe it resides within is made of carbon fiber, + which is opaque to RF signals, you may choose to have an SMA connector + installed so that you can run a coaxial cable to an antenna mounted + elsewhere in the rocket. -
- In the Rocket - - In the rocket itself, you just need a [TeleMetrum](../TeleMetrum) board and - a LiPo rechargeable battery. An 860mAh battery weighs less than a 9V - alkaline battery, and will run a [TeleMetrum](../TeleMetrum) for hours. - - - By default, we ship TeleMetrum with a simple wire antenna. If your - electronics bay or the airframe it resides within is made of carbon fiber, - which is opaque to RF signals, you may choose to have an SMA connector - installed so that you can run a coaxial cable to an antenna mounted - elsewhere in the rocket. - -
-
- On the Ground - - To receive the data stream from the rocket, you need an antenna and short - feedline connected to one of our [TeleDongle](../TeleDongle) units. The - TeleDongle in turn plugs directly into the USB port on a notebook - computer. Because TeleDongle looks like a simple serial port, your computer - does not require special device drivers... just plug it in. - - - Right now, all of our application software is written for Linux. However, - because we understand that many people run Windows or MacOS, we are working - on a new ground station program written in Java that should work on all - operating systems. - - - After the flight, you can use the RF link to extract the more detailed data - logged in the rocket, or you can use a mini USB cable to plug into the - TeleMetrum board directly. Pulling out the data without having to open up - the rocket is pretty cool! A USB cable is also how you charge the LiPo - battery, so you'll want one of those anyway... the same cable used by lots - of digital cameras and other modern electronic stuff will work fine. - - - If your rocket lands out of sight, you may enjoy having a hand-held GPS - receiver, so that you can put in a waypoint for the last reported rocket - position before touch-down. This makes looking for your rocket a lot like - Geo-Cacheing... just go to the waypoint and look around starting from there. - - - You may also enjoy having a ham radio "HT" that covers the 70cm band... you - can use that with your antenna to direction-find the rocket on the ground - the same way you can use a Walston or Beeline tracker. This can be handy - if the rocket is hiding in sage brush or a tree, or if the last GPS position - doesn't get you close enough because the rocket dropped into a canyon, or - the wind is blowing it across a dry lake bed, or something like that... Keith - and Bdale both currently own and use the Yaesu VX-7R at launches. - - - So, to recap, on the ground the hardware you'll need includes: - - - an antenna and feedline - - - a TeleDongle - - - a notebook computer - - - optionally, a handheld GPS receiver - - - optionally, an HT or receiver covering 435 Mhz - - - - - The best hand-held commercial directional antennas we've found for radio - direction finding rockets are from - - Arrow Antennas. - - The 440-3 and 440-5 are both good choices for finding a - TeleMetrum-equipped rocket when used with a suitable 70cm HT. - -
-
- Data Analysis - - Our software makes it easy to log the data from each flight, both the - telemetry received over the RF link during the flight itself, and the more - complete data log recorded in the DataFlash memory on the TeleMetrum - board. Once this data is on your computer, our postflight tools make it - easy to quickly get to the numbers everyone wants, like apogee altitude, - max acceleration, and max velocity. You can also generate and view a - standard set of plots showing the altitude, acceleration, and - velocity of the rocket during flight. And you can even export a data file - useable with Google Maps and Google Earth for visualizing the flight path - in two or three dimensions! - - - Our ultimate goal is to emit a set of files for each flight that can be - published as a web page per flight, or just viewed on your local disk with - a web browser. - -
-
- Future Plans - - In the future, we intend to offer "companion boards" for the rocket that will - plug in to TeleMetrum to collect additional data, provide more pyro channels, - and so forth. A reference design for a companion board will be documented - soon, and will be compatible with open source Arduino programming tools. - - - We are also working on the design of a hand-held ground terminal that will - allow monitoring the rocket's status, collecting data during flight, and - logging data after flight without the need for a notebook computer on the - flight line. Particularly since it is so difficult to read most notebook - screens in direct sunlight, we think this will be a great thing to have. - - - Because all of our work is open, both the hardware designs and the software, - if you have some great idea for an addition to the current Altus Metrum family, - 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... - -
- - How GPS Works - + On the Ground + + To receive the data stream from the rocket, you need an antenna and short + feedline connected to one of our [TeleDongle](../TeleDongle) units. The + TeleDongle in turn plugs directly into the USB port on a notebook + computer. Because TeleDongle looks like a simple serial port, your computer + does not require special device drivers... just plug it in. + + + Right now, all of our application software is written for Linux. However, + because we understand that many people run Windows or MacOS, we are working + on a new ground station program written in Java that should work on all + operating systems. + - Placeholder. + After the flight, you can use the RF link to extract the more detailed data + logged in the rocket, or you can use a mini USB cable to plug into the + TeleMetrum board directly. Pulling out the data without having to open up + the rocket is pretty cool! A USB cable is also how you charge the LiPo + battery, so you'll want one of those anyway... the same cable used by lots + of digital cameras and other modern electronic stuff will work fine. + + + If your rocket lands out of sight, you may enjoy having a hand-held GPS + receiver, so that you can put in a waypoint for the last reported rocket + position before touch-down. This makes looking for your rocket a lot like + Geo-Cacheing... just go to the waypoint and look around starting from there. + + + You may also enjoy having a ham radio "HT" that covers the 70cm band... you + can use that with your antenna to direction-find the rocket on the ground + the same way you can use a Walston or Beeline tracker. This can be handy + if the rocket is hiding in sage brush or a tree, or if the last GPS position + doesn't get you close enough because the rocket dropped into a canyon, or + the wind is blowing it across a dry lake bed, or something like that... Keith + and Bdale both currently own and use the Yaesu VX-7R at launches. + + + So, to recap, on the ground the hardware you'll need includes: + + + an antenna and feedline + + + a TeleDongle + + + a notebook computer + + + optionally, a handheld GPS receiver + + + optionally, an HT or receiver covering 435 Mhz + + + + + The best hand-held commercial directional antennas we've found for radio + direction finding rockets are from + + Arrow Antennas. + + The 440-3 and 440-5 are both good choices for finding a + TeleMetrum-equipped rocket when used with a suitable 70cm HT.
- - - +
+ Data Analysis + + Our software makes it easy to log the data from each flight, both the + telemetry received over the RF link during the flight itself, and the more + complete data log recorded in the DataFlash memory on the TeleMetrum + board. Once this data is on your computer, our postflight tools make it + easy to quickly get to the numbers everyone wants, like apogee altitude, + max acceleration, and max velocity. You can also generate and view a + standard set of plots showing the altitude, acceleration, and + velocity of the rocket during flight. And you can even export a data file + useable with Google Maps and Google Earth for visualizing the flight path + in two or three dimensions! + + + Our ultimate goal is to emit a set of files for each flight that can be + published as a web page per flight, or just viewed on your local disk with + a web browser. + +
+
+ Future Plans + + In the future, we intend to offer "companion boards" for the rocket that will + plug in to TeleMetrum to collect additional data, provide more pyro channels, + and so forth. A reference design for a companion board will be documented + soon, and will be compatible with open source Arduino programming tools. + + + We are also working on the design of a hand-held ground terminal that will + allow monitoring the rocket's status, collecting data during flight, and + logging data after flight without the need for a notebook computer on the + flight line. Particularly since it is so difficult to read most notebook + screens in direct sunlight, we think this will be a great thing to have. + + + Because all of our work is open, both the hardware designs and the software, + if you have some great idea for an addition to the current Altus Metrum family, + 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... + +
+
+
+ + How GPS Works + + + Placeholder. + +
+ + + -- cgit v1.2.3