1.
Purpose ...................................................................................................................................................... 3
2.
Version Status ............................................................................................................................................ 3
3.
Compatibility and Compilation .................................................................................................................. 3
IDE ........................................................................................................................................................... 3
Arduino Board ......................................................................................................................................... 3
4.
Hardware ................................................................................................................................................... 4
Major Components ..................................................................................................................................... 4
Pin Allocation .............................................................................................................................................. 4
I2C ............................................................................................................................................................... 4
Wiring Diagram ........................................................................................................................................... 5
5.
Code Structure ........................................................................................................................................... 6
State Machine ............................................................................................................................................. 6
States .......................................................................................................................................................... 6
Unknown or TimeOut ............................................................................................................................. 6
Monitor ................................................................................................................................................... 7
Fill, Empty, Fast Fill, Fast Empty .............................................................................................................. 7
Sensor Class Objects ................................................................................................................................... 7
Error Handling ............................................................................................................................................. 8
6.
User Settings .............................................................................................................................................. 8
#define Options .......................................................................................................................................... 8
Default Values (initalvals.h) ........................................................................................................................ 8
7.
Tests........................................................................................................................................................... 9
8.
Recommendations ..................................................................................................................................... 9
Known Issues .............................................................................................................................................. 9
1

Second Differential Pressure Sensor ....................................................................................................... 9
ESC Arming .............................................................................................................................................. 9
Future Developments ................................................................................................................................. 9
Altitude Monitoring ..............................................................................................................................10
Logging to EEPROM or SDcard ..............................................................................................................10
Power Supply Monitoring .....................................................................................................................10
Serial Menus and Remote Monitoring ..................................................................................................10
9.
Contact/Support ......................................................................................................................................10
2

Arduino code to run a prototype pressure control system for regulating the pumping/venting of air into ballonet of a medium sized (~10mx3m) soft-bodied unmanned blimp/aerostat for the purpose of maintaining acceptable envelop pressure.
At the core of this system are two differential pressure sensors, a servo actuated valve and an ESC controlled pump/blower.
Version 0.9 (a.k.a. V0_9)
NOTE: This version is NOT fully tested. (See sections below)
This version hopes to provide a code structure that can, with as little further modification and testing as possible, provide an adequate (but not optimal) deployable system design.
This system would employ a naïve, hysteresis based approach, but the code is structured in such a way that future versions could be improved to utilize more sophisticated algorithms, specifically PID and/or
Adaptive control, without any major code or hardware restructuring.
This Arduino project requires the following files to be contained in a folder named “Balonet_Final” to compile:
Balonet_Final.ino controller.h
DiffPresSensor.h
ERR.h flow.ino initiaVals.h menus.ino
Non vital components:
TempSensor.h eeprom.ino
AltitudeSensor.h
Logging.ino
(see section…)
[Optional Modules]
[Optional Modules]
[Future]
[Future]
Developed using the Arduino IDE version 1.5.5
Future versions of the IDE may (probably) or may not be back compatible. (Refer to the official website for more information about versions and compatibility; http://arduino.cc/en/main/software )
Developed for use on an Arduino R3.
This should work equally well with other Arduino based boards (e.g. ProMini, or Ethernet board). It is
3

possible that different boards may have different requirements/capabilities. If using a different Arduino board, eeprom.ino and logging.ino will in particular, need reviewing/testing.
The following table outlines the components used in this system. In addition, several basic components
(resistors, capacitors, etc.) are required but not listed here (see [Wiring Diagram] for details).
Component Type
Board/Controller
Differential Pressure Sensors
Temperature Sensor
Altitude Sensor
ESC
Pump/Blower
Valve/Servo
I2C Level converter
Mini Piezo Buzzer
Item Used
CLASSIFIED (NOT FOR PUBLICATION)
CLASSIFIED (NOT FOR PUBLICATION)
CLASSIFIED (NOT FOR PUBLICATION)
CLASSIFIED (NOT FOR PUBLICATION)
CLASSIFIED (NOT FOR PUBLICATION)
CLASSIFIED (NOT FOR PUBLICATION)
CLASSIFIED (NOT FOR PUBLICATION)
CLASSIFIED (NOT FOR PUBLICATION)
CLASSIFIED (NOT FOR PUBLICATION)
The following table contains a list of utilised I/O pins from the Arduino board.
Greyed out lines are pins that have been reserved for future use but are not implemented in this version
In Code
//PIN_altIntrpt
Name
//PIN_debugSwitch
//PIN_debugLED
PIN_ERRLED
PIN_ERRalarm
PIN_valveServo
PIN_pumpDSC
//PIN_supplyVolt
-na- [see I2C]
-na- [see I2C]
Type
On Board
4 Digital In
5 Digital In
6 Digital Out
7 Digital Out
8 Digital Out
9 PWM Out
10 PWM Out
Use
To trigger and interrupt when altitude is changing rapidly [future]
To toggle functionality during testing
Visual feedback during testing via an LED
Visual output of error codes via an LED
Sound output to notify of errors via an piezo buzzer
Pulse width modulated servo control signal output
Pulse width modulated ESC control signal output
A1 Analogue In To monitor the voltage of the supply line/battery [future]
A4 Analogue I&O SDA (data line) used by wire library for I2C communications.
A5 Analogue I&O SCL (clock line) used by wire library for I2C communications.
Many of the Sensors listed above use I2C (a.k.a. Two-Wire Interface; TWI) a digital communication protocol to all connect (as slave devices) to the Arduino board (master) using just two (analogue) pins. It is important to note, however, that some of these devices operate at 3.3V as opposed to the 5V of the
Arduino board. To mitigate this issue (there by lowering risk of sensor failure and improving reading accuracy/consistency), a bi-directional 3.3V – 5V logic level converter is used to partition the I2C bus in two while allowing transparent throughput. See the [wiring diagram] for further details.
The following table list the I2C addresses used/reserved for use in this project.
4

Device Object Name (in Code) 7-Bit Address (Hex) Notes [See Section]
Diff. Pressure Sensors
Diff. Pressure Sensors
Temperature Sensor
Temperature Sensor
Altitude Sensor
DiffPSensor EnvExtP
DiffPSensor BalEnvP
EnvTemp
BalTemp
// na
0x28
0x36
0x48
0x49
0x60
Vital Core Component
[Known Issues]
[Optional Modules]
[Optional Modules]
Not implemented, [Future]
The provided I2C scanner can be used to see which devices are contactable. See [Tests] for more details.
CLASSIFIED (NOT FOR PUBLICATION)
5

The core logic design is a sate machine with the following states of operation
State #define Name Value Description
CM_UNKNOWN
CM_MONITOR
CM_FILL
CM_EMPT
CM_FASTFILL
CM_FASTEMPT
0x00 Starts here and returns if an unexpected transition is called for.
0x01 Pressure is ok. Do non critical tasks and wait.
0x02 Pressure is too low. Pump is running to fill the ballonet.
0x03 Pressure is too high. Valve is open to vent from the ballonet.
0x04 Pressure is much too low. Pumping fast to fill the ballonet rapidly.
0x05 Pressure is much too high. Venting fast from the ballonet.
The actions in each stat are described in the next sub-section. The state machine is implemented by the controller class object in the code.
Each state has a time out period. If the state machine stays in a given state for too long, the main loop will move to stop and reassess the situation (in the same way it does at start up or when state is
CM_UNKNOWN).
This stat is the start and recovery point for the system.
It starts by shutting down the pump and closing off the valve, collectively referred as flow stop.
It also logs any error or timeout that occurred that put it here.
The system then runs a full fault check, and takes actions accordingly if required.
If all is well, the system takes new reading(s) from the Envelope-
External differential pressure sensor to determine a new average reading.
The next state is then selected by finding which Pressure Band this new average lies in. A short time out period is started and the next state entered.
6

When the pressure is within the desired range the controller mode is monitor. This has a long time out period. If timeout occurs the controller directs to the unknown/timout actions described above.
If the monitor is not timed out, the opportunity is taken to do a full fault test and addresses any faults discovered.
Then the Env-Ext pressure is tested and if it has moved outside the desired range the controller moves to the appropriate state
(presumably fill or empty but a move directly into fast is possible).
Otherwise the Monitor can take other readings (eg Temperature, altitude), log any recent events (refer to [Future]) and delay/sleep before beginning again.
These four states operate in a similar way.
When entering them the timeout period is set.
The loop begins with a time out check (as above), and then a limited err check. This check is different per state but for example when filling this includes a check to ensure that the ballonet can still be inflated further.
A new Env-Ext pressure reading is taken. If this is not past the relevant stop (above if filling, below if venting), it loops back after a brief delay (unless the fill/vent is too slow, in which chase it shifts to fast mode if not already in it).
If the stop is passed, a new reading is placed in a band. If this is not the monitor or the slower version of the current mode, (i.e. recommends a direct move from fill to vent or vice versa) a brief delay is introduced and move into unknown state to double check.
Otherwise the recommended mode is started.
Each type of sensor has its own class object containing, both protected and public, variables and functions. The constructor for each class if of the form thing1=somethingSensor(address) where is the 7bit I2C address of the device (see [I2C] for details). Where multiple of the same sensor are used the constructer is called once for each, just with the different address each time.
To verify that the sensor is responsive, the thing1.test() function is used. This will return 0 if everything is fine otherwise returning a byte error code. The .test() also sets the .isOK Boolean.
The .current(), .average(), and .trend() functions return the most recent value, 2 sample average, and 2 sample mean respectively. To poll the sensor and update these values use .newCurrent().
7

Values returned are of type unsigned int which is the count value of the sensor. To convert these count values to meaningful units (or vice versa) several useful functions are provided in menus.ino. See the relevant data sheets for more details.
A (currently quite simplistic) error handling system has been implemented. The primary function is to alert the user if an error occurs, what type of error it was, and to lock down the system to prevent it from becoming worse than nothing.
When a test condition indicates an error, it should call errorReporter(ERR_code), where ERR_code is a byte specified by a #define at the top of ERR.h.
If the error renders the system inoperable, the variable GL_FATAL_ERROR is set to true and the system attempts to lockdown into an infinite loop. (Optionally the system can be configured to attempt a cold restart).
Several user setting are made before the code is compiled through the use of #define and #if statements.
These options are listed at the top of the main Ballnet_final.ino file and either true/false or a positive integer value.
SERIALMON__ON (true/false)
This should almost certainly be left as true. Setting to false will suppress all use of the serial monitor. Only necessary if ported to a very slow processor where serial print time delay is unacceptably long.
FULLDEBUG__ON (true/false)
If true, additional serial print statements will be activated (must have the serial monitor on) to allow better understanding of internal workings for debugging or fault finding. Additionally the system will wait for a user input form serial at several points (especially during set up). Not intended to be left on when deploying the system in the field (in which case it should be set to false).
SIMULATION__ON (true/false)
If true, instead of polling the sensors for data the system will prompt of external input (either from user or additional test hardware) via the serial connection (therefor requires SERIALMON__ON to be true). NB: not fully implemented in this version.
FLOWCONTROLMODE (0, 1, or 2)
Modes other than 0 not implemented yet. See [Future].
Set to 0 to make the system will use hysteresis mode, 1 for PID or 2 for Adaptive. Would allow the user to specify the type of control system to implement.
Many numerical settings can be made by changing the values listed in the initalvals.h file. Many of these are very hardware dependent, and will have to be calibrated by further testing (trial and error).
8

The idea of the pressure bans is to split the range of measurable pressures into five different bands relating to acceptable, low, high, very low and very high. In each region, different mode of operation will be required. Once a given action is begun, it should continue until the pressure reaches a given Stop value.
Together the bands and stop values create a hysteresis for every mode of operation.
Several Pieces of test code are provided in addition to the main system. These are intended to be used as aids for system validation, debugging and or calibration. Each should sufficiently self-documenting and would serve as a good place to start understanding the code.
CLASSIFIED (NOT FOR PUBLICATION)
The Electronic Speed Controller (ESC) used to control the blower/pump during testing was a generic one of the type used in remote control vehicles. There was significant difficulty trying to find a method which would successfully arm the ESC, and keep it armed every time. This is a serious issue, as failure to do so would result in the pump being inactive and the ballonet valve being opened further, worsening the low pressure.
Recommend use of a more consistent ESC, or one which does not require a PWM arm sequence.
Modification to the code will be required.
Several other features were considered during development, but were either abandoned or not investigated due to time limitations. The following extensions to the system’s capabilities could (or even should) be implemented without extensive code additions/changes.
9

As significant and rapid changes to the airship’s pressure will occur during the ascent and descent stages, the use of and altitude measurement could be useful in maintaining rigidity during these mauvers. The
MPL3115A2 absolute pressure sensor/temperature sensor can be easily added to the I2C lines and has the capability sending the Arduino a signal whenever it senses altitude changing quicker than a set rate. I suggest that it may be useful have 3 different copies of the PressureStops class, one for each of ascent, descent and stable flight.
It would be easily possible to implement a function to log system events and errors/warning, to either the
Arduino’s on board EEPROM or via an external SDcard module (potentially via I2C). This would be very useful in accessing the system’s long term performance when it can’t be observed directly, discovering rare errors, or when events are too rapid or numerous to observe directly.
If this were to be deployed for long periods or with its own power supply, it would be recommended that a function be added that could monitor the voltage of the supply line. Of particular concern might be the risk of the system losing power when attempting to run the blower.
If a set of multiple choice type menus were added, it would potentially be possible to modify many of the settings without access to the source code or reprograming the device. Doing so would also open up the possibility of requesting specific information while in operation as well.
Design and code developed by Alexander Brazel for Shift Geophysics. It is very much in the prototype stages of development, and requires significant testing and review before it should be used. The code/design is provided in its current stat, as is with no guarantees what so ever.
If you intend to develop this code and wish to contact me you can do so by any of the following methods.
Email: Alexander.Brazel@gmail.com
Mobile: 0423 964 602
Home: (03) 9887 8849
Mail: 3 Glenwerri Ct, Vermont South, 3133
10