This web page summarizes some recent Nadler & Associates embedded projects, including links for further information.
Ballast dump systems for racing gliders have been plagued by reliability problems, and its just too exciting flying them with only one wing full of water (and even more exciting landing them with one wing heavy). Dave proposed a new dump valve system and demonstrated the concept to Lange Aviation. Lange designed and built the valve assembly per Dave's suggestions (patent application in progress). Nadler & Associates designed and built the valve controller (electronic design plus software, one controller in each wing plus tail actuates the new valves). Nadler & Associates also designed the electronics for the pilot interface installed in the cockpit. The new valve controller features:
Drive and position-reporting electronics for 6 valves,
Electrically-isolated CAN-bus control interface (backwards compatible for retrofits),
ARM Cortex-M0 processor (running FreeRTOS; note Dave contributed to the CM0 port of FreeRTOS),
Development using CodeRed/Eclipse C toolchain,
Power supplies and PWM controls for optional servos (Antares battery ventilation etc), and
Electronic design (schematic capture and board layout) using Eagle 5.11
All Lange Antares and Schempp-Hirth Quintus gliders are now produced with this system.
Here's a Quintus M dumping water with this system during a high-speed pull-up:
News Flash Saturday, August 18th, 2012 !
France's Laurent Aboulin, flying a Quintus M,
wins 2012 World Open Class Championships in Uvalde Texas !
With this water system ;-)
Four of top ten places in the world championship
were won by Antares 23 or Quintus M racers equipped with this water system.
Nadler & Associates is a Microchip Design Partner and
specializes in designing with Microchip products.
Visit the Microchip Technology web site for more information on PIC microcontrollers and other Microchip products. |
|
Dave has worked to get the FLARM aircraft collision-warning system deployed in USA for several years. In early 2010 Dave asked FLARM group what he could do to get this moving, which led to consulting on the next-generation PowerFLARM products and FLARM version 5 software. Now, version 5 is now flying world-wide in around 16000 legacy FLARM devices and all new PowerFLARM devices. Dave's contributions included:
Refactored the original code, so that all high-level collision-detection and RF-messaging code is free of legacy AVR platform dependencies and runs unchanged on legacy AVR, new ARM, and PC unit-test platforms,
Improved testability including unit tests plus embedded-platform logging and playback facilities,
Added RF frequency-hopping for USA FCC-compliance and more robust operation,
Implemented low-level code for FLARM functions on new PowerFLARM ARM platform,
Improved state machine and alarm processing for PowerFLARM version,
Added extensive code and engineering documentation (doxygen, state machine, etc),
Enhanced RF protocol for future features,
Test-flew version 5 on legacy FLARM and PowerFLARM (in Australia during November 2010),
Promoted FLARM in USA via writing (see FLARM motivation and description on www.GliderPilot.org) and speaking (SSA national convention 2010, 2011 and 2012, and other events), leading to more than 600 advance orders,
Helped arrange FLARM marketing, distribution, and sales in USA,
Resolved USA-specific problems with early deliveries, and
Training and knowledge-transfer for a new developer at FLARM (in Zurich fall 2011).
Delivery of PowerFLARM portable units (shown below)
commenced in Europe spring 2011, and in USA August-2011.
Fixed-mount (blind mounting) PowerFLARM "brick" units
commenced shipping beginning 2012,
and USA deliveries are now approaching 1000 units.
For the ILEC SN10 avionics product (developed by Nadler & Associates and ILEC GmbH), we developed a USB adapter add-on product. With the USB adapter and a USB memory stick (thumb-drive), a pilot can:
Save a flight log from the ILEC SN10 to the thumb-drive,
Load a new waypoint and airspace-boundary database from the thumb-drive into the ILEC SN10,
Load a new ILEC SN10 software version from the thumb-drive into the ILEC SN10, and
Load a software update for the USB-adapter.
These functions previously required the pilot to take a laptop PC to the aircraft and use a serial cable to connect to the instrument panel.
Technical requirements to develop the USB add-on included:
USB-host function including USB-stack and FAT file system
Communicate with the ILEC SN10 over its embedded RS-485-based LAN
Run more than ten thousand lines of C++ already running on PC (parse database files and transmit to SN10, parse SN10 software updates and transmit to SN10) - not all toolchains support C++
Boot-loader for in-the-field updates of the USB add-on software from a USB thumb-drive
Nadler & Associates did the product architecture, hardware design, and software. ILEC GmbH did the PCB layout and mechanical design. For this product we used the Microchip PIC32 processor. We used the CodeSourcery G++ C++ compiler for MIPS with some adaptations for G++ MIPS cross-compiler for PIC32. To complete this project we implemented a number of work-arounds for Microchip tool issues. Our initial attempt at this product used the Freescale MCF51JM128 “Flexis” 32-bit processor, but the tools provided for this part proved unworkable and drove our switch to Microchip (see MCF51JM128 eval problems for details).
An existing GSM-equipped Linux-based product used the obsolete CSD system for remote access (see CSD explanation on Wikipedia). CSD permitted easy access: the service technician dialed the mobile number just like an old analog modem. Unfortunately CSD is not available worldwide and is being discontinued in locales where still available. New GSM modules provide internet access, where the module initiates a connection and the service provider (telco) provides a connection to the public internet from behind a NAT and firewall. Because the connection is behind the telco NAT box and firewall, it cannot be accessed from the public internet. Similarly, the service technician is normally hidden behind a NAT facility, so the embedded system cannot initiate a connection to the technician. Each party is thus effectively invisible to the other.
We implemented a solution using OpenVPN (thanks to ORT for the suggestion and help with this):
The technician initiates a service connection by sending a text message to the embedded system,
On receipt of the text message, the embedded system initiates a connection to the internet,
The embedded system initiates an OpenVPN connection to a third-party service provider at a publicly-accesible address,
The third-party provider serves the OpenVPN connection and bridges (tunnels) it to a separate publicly-accesible address where...
The service technician connects to the other side of the bridge (using telnet for example).
Thus, the service technician can connect to the embedded system from any location using the public internet, and no longer requires a GSM modem to do so. Additionally, OpenVPN consolidates traffic to all ports through a well-known and firewall-supported port, so multiple port connections can be used without firewall difficulties (for example, to use FTP between the technician's machine and the embedded system).
Copyright © 2009-2013 - Dave Nadler - All Rights Reserved
Most recent edit: 15-November-2013
Contact Dave Nadler:
USA East Coast voice (978) 263-0097
Skype Dave.Nadler1
Dave.Nadler@Nadler.com
Nadler & Associates Home Page