[]

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.

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

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 here

• Mobile
• Stationary Off-Grid
  • Offline
  • Online
    • Hibernating
    • Basic Operation
    • Full Operation
• Stationary On-Grid

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

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)

[] []

jupiter

http://www.jtxp.org/tech/XR232circuit_v20_HiRes.gif

Honeywell tilt compensated MEMS Compass Module HMC4363

• SKU ↔ MCU (tcp)
• SKU ↔ PDU (RS232 ↔ PDU Daemon in python)

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

position-to-timezone

ucsspm

• Button-panel with led status on/off
• Display (budget dependent)

The following table is a documentation of the latest Netus/Foxboard G20 connections to the 60603-2C (DIN 41612) Header (96-Pins):