User Tools

Site Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
mission:tech:odyssey:sku [2012/06/29 08:21] – [Software] chronomission:tech:odyssey:sku [2014/11/22 19:22] (current) – [Station Keeping Unit (SKU)] chrono
Line 1: Line 1:
 +====== Station Keeping Unit (SKU) ======
  
 +[{{ :mission:tech:odyssey:foxg20.jpg?270|Fox/Netus G20 with Atmel AT91SAM9G20}}]
 +
 +The purpose of the SKU is to monitor, analyze and control all of Odyssey's subsystems as well as to provide mandatory system features:
 +
 +  * Positioning
 +  * Precision Time-Keeping
 +  * Power controlling
 +  * System-Alerting/Monitoring
 +  * Basic Vehicle Operating & Module-Communication System
 +
 +It will also monitor and record habitual & mobile environmental parameters (external/internal), in order to develop power consumption/harvesting profiles which may propose either a change in power usage behaviour or a change in power harvesting methods so that we can maximize efficiency and prolong battery live by reducing charge/discharge cycles. In short, all designated house- and station-keeping tasks will be controlled by this unit. 
 +
 +It is meant to be always kept powered on, so the power consumption budget of the SKU is very demanding. The Goal was to deploy a system that will not draw more than 1-2W in full system operation mode, the current implementation of the SKU draws **less than 1W**, running Gentoo-Linux, gpsd, chrony, collectd and USB/SD data storage units.
 + 
 +~~CL~~
 +=====Hardware platform=====
 +
 +
 +After researching different embedded solutions the choice went in favour of the Acme-Systems Netus G20 system, with an ATMEL AT91SAM9G20 400MHz ARM9 CPU (max. 50mW@25°C = 0.125mw/MHz) and 64MB/1.8V BGA SDRAM(532MB/s), to reduce power comsumption and due to the mobile nature of the SDRAM, enabling low power modes, claiming a total of 80mA@5V (0.4W) idle power consumption. Although the Cortex A5 offers more than twice the DMips/W amount, the broader availability, the price and the available amount of documentation on the internet lead to the Netus G20, produced by Acme-Systems, Italy. It was also considered to use an ATMega32 as SKU but the idea was abandoned because a real Linux can offer more features off the shelf and seems a much more flexible solution than to reinvent everything on a uC level. Temperature range: -15 to +70 Celsius degree (°C).
 +\\
 +
 +^CPU^Mhz^DMIPS^mW^mw/Mhz^DMips/Watt^Used in^
 +|Intel Atom N270|1600|4000|10000|6.3|400|low-end miniitx / netbooks|
 +|Intel Atom Z515|1200|2500|3600|3.0|830|mid-range netbooks/miniitx /w US15W |
 +|Arm9 old|200|220|260|1.3|830|Smartphones, embedded boards, routerboard|
 +|**Arm9 new**|400|450|50|0.13|**5500**|Smartphones, newer embedded boards, FOX G20|
 +|Arm11|600|780|360|0.6|2000|Smartphones, iPhone 3G|
 +|Arm Cortex A8|1100|1500|500|0.45|3500|Smartphones (3GS), netbooks|
 +|**Cortex A5**|480|700|60|0.12|**13000**|Smartphones NG|
 +|AVR32|150|210|150|1.0|1400|embedded (atmel/avr) boards|
 +
 +
 +=====Operating System and Software=====
 +
 +The underlying Operating System will be Gentoo with a custom portage tree for the individual house- and station-keeping modules. The Development and compilation shall be done in a chroot container either on the MCU when mobile or the HP DL380 when stationary and on-grid, for fast deployment.
 +
 +  * Chrony 
 +  * GPSD 
 +  * TPV Logging 
 +  * Watchdogs
 +  * CollectD
 +
 +For more Info about the SKU Software go [[mission:tech:odyssey:sku:software|here]]
 +
 +===== Station Keeping Runlevel =====
 +
 +  * Mobile
 +  * Stationary Off-Grid
 +    * Offline
 +    * Online
 +      * Hibernating
 +      * Basic Operation
 +      * Full Operation
 +  * Stationary On-Grid
 +
 +===== External Peripherals =====
 +
 +{{:mission:tech:odyssey:sku-block.png?560|}}
 +
 +
 +The SKU gathers relevant performance/environment data, provides mandatory network services and controls the system mostly through external periphery, which has to be kept modular in order to 
 +  * leave room for future optimization 
 +  * maintain overall system funcionality - in case of single module malfunction
 +  * modules can be used otherwise when the system doesn't need it
 +  * keep power consumption low by only supplying power to active modules
 +  * off the shelf usb modules have a bigger chance to be quickly replaced on the road in different countries
 +
 +
 +^Name^Connect via^U^I^Purpose^
 +|Rockwell/Connexant Jupiter TU30-420-031|3.3V Serial + DCD|3.3|0.15|Time & Frequency 10 khz -> GPS disciplined clock/10MHz OCXO|
 +|uBlox LEA-6T|3.3V Serial + DCD|3.3|-|Time & Frequency GPS disciplined clock/10MHz OCXO|
 +|uBlox LEA-6R|3.3V Serial RX-only|3.3|-|PV + Dead-Reckoning|
 +|CUL-868|USB|5|?|ISM 868 MHz Mastercontroller|
 +|USB UMTS/GPRS (PrePaid)|USB|5|?|Failsafe Datalink|
 +|USB WLAN 802.11a/g/n?|USB or SPI|3.3|?|Primary Datalink|
 +|PDU sensor input|3.3V Serial RX|3.3|?|Log PDU sensor data|
 +|PDU switch output|3.3V Serial TX|3.3|?|Switch Power buses|
 +|DS1820 Tempsensors|1-Wire|3.3|0.001|Temperatur sensor Bus (-55/+125°C@9-12bit)|
 +
 +==== GPS ====
 +
 +It was more by accident than intention that I was able to get one of the old Rockwell/Connexant Jupiter TU30-420-031 GPS receivers on eBay. The earlier plans involved 2 GPS Systems, one for PV (Position/Velocity) and one for TF (Timing/Frequency) purposes. They were also supposed to back each other up (one module fails, the other will take over PV or TF duties as secondary system). 
 +
 +As it turned out the TU30-420-031 is not only capable of supplying the rare GPS disciplined 10kHz frequency output feature, I originally wanted it for, but it is also capable of dead-reckoning. Even when satellite reception is lost due to a tunnel/building, the gps will measure the speed/distance, given by the car's wheel sensor ticks and the rotation around the z-axis (going left/right) by measuring the analog output of a gyro sensor (ADXRS610). The driving direction (for/rev) is also taken into account, I guess I'll take the reverse-light power as input for this. 
 +
 +Altough I cursed myself at first for buying a 3.3V model, I came to realize how lucky I've been. Since the SKU base board is a 3.3V model I hooked it up directly to ttyS1 (RX/TX and PPS on DCD) - ttyS1 is the only serial interface on the Netus G20, that supports all serial pins (including DCD). Although there are patches to use CTS as PPS input I opted for DCD.
 +
 +The only problem with 3.3V was, that the GPSDO had to be redesigned to work with the 3.3V 10kHz frequency to PLL sync the OCXOs 10MHz ouput.
 +
 +The GPS module is responsible for the following features:
 +
 +  * GPS PV Data for navigation subsystems (GPSD)
 +  * Dead-Reckoning PV data for navigation systems (GPSD)
 +  * Stratum 1 time sync capabilities (Chrony/Kernel)
 +    * Kernel PPS through DCD
 +    * Chrony GPSD socket sync (nanosecond deviation)
 +  * 10kHz GPS disciplined frequency (->GPSDO Module)  
 +
 +[{{:mission:log:2011-09-27:jupiter_chrony_time_offset_utc.png?295|Ref. Time-Offset to UTC}}]
 +[{{:mission:log:2011-09-27:jupiter_gps_visible_sats.png?295|GPS - Visible Sats}}]
 +
 +[[apollo:hardware:sku:jupiter]]
 +
 +
 +
 +
 +==== RNG ====
 +
 +http://www.jtxp.org/tech/XR232circuit_v20_HiRes.gif
 +
 +
 +==== IMU ====
 +
 +===Accelerate===
 +===Gyro===
 +===Compass===
 +
 +Honeywell tilt compensated MEMS Compass Module HMC4363
 +
 +===== Interfaces =====
 +
 +==== Software ====
 +
 +  * SKU <-> [[mission:tech:odyssey:mcu|MCU]] (tcp)
 +  * SKU <-> [[mission:tech:odyssey:pdu|PDU]] (RS232 <-> PDU Daemon in python)
 +
 +=== Position to Timezone Tracking ===
 +
 +Apollo-NG's primary clock is always UTC. As a moving element, we will pass through different local time zones, we should be aware of. When passing a timezone boundary, Apollo-NG will notify the crew and change the secondary clock (localtime) according to the current timezone (including correct DST offsets as well).
 +
 +[[mission:tech:odyssey:sku:position-to-timezone]]
 +
 +
 +=== Solar-Output prediction model ===
 +
 +[[lab:ucsspm]]
 +==== User ====
 +
 +  * Button-panel with led status on/off
 +  * Display (budget dependent)
 +
 +
 +===== Notes =====
 +
 +==== SKU - EN/IEC 60603-2C Header ====
 +
 +The following table is a documentation of the latest Netus/Foxboard G20 connections to the 60603-2C (DIN 41612) Header (96-Pins):
 +
 +^ FOX ^ PIN ^ Description ^  A  ^  B  ^  C  ^
 +| J6.08 | RXD0 | Receive GPS data on ttyS1 |  23  | | |
 +| J6.09 | TXD0 | Transmit data ttyS1 | |  23  | |
 +| J7.31 | DCD0 | PPS0 Timepulse input | | |  23  |
 +|J6.15 | RXD5 | Receive PDU data ttyS6 |  4  | | |
 +|J6.16 | TXD5 | Transmit PDU data ttyS6 | | |  4  |
 +| J6.30 | AD0 | Analog input 0 |  28  |  28  |  28  |
 +|  | 1W VCC | OneWire VCC |  1  |  |  |
 +|  | 1W DATA | OneWire DATA |  |  2  |  |
 +|  | 1W GND | OneWire GND |  |  |  3  |
 +|  | Sys VCC | System VCC |  28  |  28  |  28  |
 +|  | Sys GND | System GND |  26  |  26  |  26  |
 +| J7.40 | Sys 3V3 | System 3V3 |  32  |  32  |  32  |