Specific heat ratio value is fixed to a 1.4 value. It should be nice to have a lib function to evaluate the value.

Sensors loosely connect to the board; here you find the online PCB 3D model.
We've found some reliability problem to the prototype.
Obvious, get rid off of the sockets! :-). The point here is to maintain the possibility to remove the sensors. That was a fundamental requirement since the early ADC prototypes, that warrants easy removal for sensor calibration and differential range change. An alternative removable socket/whatever is needed here.

void AirDC::ISAAltitude(int mode), Case 2.
_uh =0. Implementation should be added.

With the $DTS string we could set some useful data, like the external temperature.
The firmware could use the status matrix to choose between two behaviors (in acquisition phase):

• Read the sensor and write the value into the appropriate field
• Put the last value (received by the $DTS string) into the appropriate field

The code need some polish

Currently the file name and the size is reported.
Now that the correct timestamp has been implemented, it would be fine to have timestamps in $FMA,LST and $FMA,PRP messages too.

The data string should be produced, saved or scheduled (with a specified frequency) by an explicit device request.
Thus, the default data frequency should be zero.
It will be possible to change it using the appropriate commands when needed, or saving a different setup configuration on SD (SD configuration file not yet implemented).

Define general structure for documentation.

It should be interesting to have a standardized workflow to be able to use the data from the ADC together with the data from the GPSLogger (check here, link live after 17/12/16)). Ideally, all the data should converge at the same software for visualization purposes. Preliminary tests showed that a GIS can handle our data.

All our files should be freely usable and editable. Right now the ADC enclosure drawings are not in an editable format. Freecad format can do the job, we need a conversion to a free editor format.

Referring to the ADC Common Message Set implementation.
Message No.19 LGA LOG_FILE_ASSERT
This message is supposed to retrieve a specific line of the log file. I'm lost about the possible criterion to index the file. The use of lines no by themselves does not seem too user-friendly. I mean, it seemed good to me in the past. Now that I have a working implementation it feels useless to me :-). Any use case is welcome :-)

The $FMQ,LST returns $FMA,LST,0 in the following cases:

• if the SD is present (inserted) and empty;
• if the SD is not present;

The two cases must be separated.:

• The first case must return $FMA,LST,0 (zero files present);
• The second case must return $FMA,LST (no list: error);

We need a programmatical procedure/files/format/whatever to
"Load ADC + GPS Logger Data into QGIS"

We need to make a test run and save all the output and take some pictures/video shoot. The test run will be possibly accompained by position and ground velocity data. All the data should be posted online.

If the user try to create a new file that already exists, the firmware could return the error $FMA,NEW?

Define exactly the method that should be implemented and the references.

BasicAirData Note. An article on the topic, with practical example, is on the way

We need to implement a method to load the setup configuration file on SDCard.
The Air Data Computer could search the file CONFIG.CFG into the SDCard on start (a one-time operation, when the user powers the device).
If the file is found, the firmware executes the commands in the file, in the same order they are written.
No additional commands are needed to implement this feature.

Different SDCards can have different setup configuration, depending on the CFG file.

Any software interface can override these settings by send a different configuration as soon as they are connected.

Expose the whole numeric method and produce a working example
Revise and expand this material
http://basicairdata.blogspot.it/2015/11/flow-rate-in-circular-pipe.html

Basic Air Data note. An article request has been put into the articles pitch queue.

Return 8 decimals for Air Viscosity[Pas] instead of 6

I need to load the GPSLogger track data into Scilab to blend the air data and the GPS Data

Spirometry seems to be a popular application. It is also a straightforward application for an ADC.
An example application should be useful.

The spirometer requires a "pipe" to work. So this hardware should be developed and tested as well.

Spirometry result should be displayed on a dedicated Android app. similar to Air Data Bridge. :-)

Create an example folder and insert the temperature logger application.

See example

Logger Example For AirData Library, http://www.basicairdata.eu, JLJ@BasicAirData 2016
$TEX,Rho[kg/m^3],_TAT[K],_TAT[C],_uTAT[K;C],_p[Pa],Viscosity[Pas1e-6],_hour,minute,second,month,day,year,millis
$TEX,1.225554,296.27,23.12,0.50,101325.00, 0.000018,23,56,15,1,7,2016,1804627
$TEX,1.225554,296.02,22.87,0.50,101325.00, 0.000018,0,11,15,1,8,2016,2704646
$TEX,1.225554,295.83,22.68,0.50,101325.00, 0.000018,0,26,15,1,8,2016,3604651
$TEX,1.225554,295.58,22.43,0.50,101325.00, 0.000018,0,41,15,1,8,2016,4504656
$TEX,1.225554,295.52,22.37,0.50,101325.00, 0.000018,0,56,15,1,8,2016,5404661
$TEX,1.225554,295.40,22.25,0.50,101325.00, 0.000018,1,11,15,1,8,2016,6304666
$TEX,1.225554,295.21,22.06,0.50,101325.00, 0.000018,1,26,15,1,8,2016,7204671
$TEX,1.225554,295.08,21.93,0.50,101325.00, 0.000018,1,41,15,1,8,2016,8104676
$TEX,1.225554,295.02,21.87,0.50,101325.00, 0.000018,1,56,15,1,8,2016,9004683
$TEX,1.225554,294.90,21.75,0.50,101325.00, 0.000018,2,11,15,1,8,2016,9904688
$TEX,1.225554,294.83,21.68,0.50,101325.00, 0.000018,2,26,15,1,8,2016,10804693

ADD new $CCS message to handle sensor hardware parameters configuration

The Dump method (from SD to the serial interfaces) now have some problems:

• It fails on large files because it fills the buffer and discards the data;
• It is a blocking operation that needs the possibility to abort it;

Under the point of view of bandwidth a "Monolithic" approach to data exchange can be a problem over a wireless link, if required sample rate is high.
Check message number 10 within Rev 1
WIP ADC DOC
I think is better instead to give the possibility to the user to receive subsets of data. In such a way it will be possible to arrange for limited bandwidth situations, low power requirements, and fast sample rate.

Implementation of the messages documented as no. 19 and no. 20 into the
ADC Common message set

I propose to make a first android app (a simple ADC Tester), in order to:

• Verify and test the ADC communication protocol;
• Find possible bottlenecks and limits of the Bluetooth interface;
• Refine protocol, transmission methods, and connection setup in order to optimize the system;
• Find the best way to implement the communication on Android-side;
• (Last but not least) Give to all users a fast and simple way to test their own DIY units;

What should be the material to keep trace of on the wiki?
Define basic structure and eventual relationships with other BasicAirData or not BasicAirData repositories

Here you can post your requirements for the Air Data Computer.

Temperature is calculated and stored in °C. We need to convert to °K.

Chekout the datalog printout. Negative density can be a problem :-)
$TEX,Rho[kg/m^3],_TAT[K],_TAT[C],_uTAT[K;C],_p[Pa],Viscosity[Pas1e-6],hour,minute,second,month,day,year,millis
$TEX,-1.268252,-273.21,-546.36,0.50,101325.00,46.007809,22,15,10,1,21,2016,1804640
$TEX,1.291896,273.40,0.25,0.50,101325.00,17.930244,22,30,10,1,21,2016,2704645
$TEX,-1.267697,-273.33,-546.48,0.50,101325.00,45.991993,22,45,10,1,21,2016,3604650
$TEX,1.291612,273.46,0.31,0.50,101325.00,17.931444,23,0,10,1,21,2016,4504655
$TEX,-1.268252,-273.21,-546.36,0.50,101325.00,46.007809,23,15,10,1,21,2016,5404660
$TEX,-1.267975,-273.27,-546.42,0.50,101325.00,45.999897,23,30,10,1,21,2016,6304667
$TEX,-1.264516,-274.02,-547.17,0.50,101325.00,45.901535,23,45,10,1,21,2016,7204673
$TEX,-1.263643,-274.21,-547.36,0.50,101325.00,45.876766,0,0,10,1,22,2016,8104679
$TEX,-1.261946,-274.58,-547.73,0.50,101325.00,45.828712,0,15,10,1,22,2016,9004685
$TEX,-1.260482,-274.90,-548.05,0.50,101325.00,45.787338,0,30,10,1,22,2016,9904691
$TEX,-1.262496,-274.46,-547.61,0.50,101325.00,45.844273,0,45,10,1,22,2016,10804697

Start Wiki

It should be nice to have a programmatically testing of calculation routines/lib. That can be done with unit testing. It will be nice to automate this process with Travis-ci. It's time to design/redesign tests.

A dedicated message should be added to the communication protocol to handle sensors zeroing and calibration data. That function should work at a raw sensor data level. Let be M the raw sensor reading; the new message should produce a new sensor output Y=a +bM. So the function will be able to change the zero and the span of the sensor measurements. To change the sensor span the user needs a reference instrument. New function should provide advanced users the possibility to incorporate calibration data/functions/tables(lookup table + interpolation). I will post in brief a possible message format.

Missing reply message 20 to message no.19 HWD

Write a detailed description of library functionalities. Actually, that information is spread out within the code and different documentation. A fresh start will be lovely.

Regarding the ADC hardware, we will switch to a numbering system similar to those used with the software. The current system is not practical under many aspects and lead to users confusion.

In general, the uncertainty implementation within the libs should be checked and enabled.

#52 will provide reduced and raw data.
We need to cross-check #52 raw data(CSV format) with Scilab/Matlab/Octave script calculated values.

Hardware of ADC Amaranth i2 is fully functional. We need to repack and to polish the minimum software bundle for the new ADC i2. The bundle should include a complete use case for the new library.

Real-time wind estimation can be useful. Preliminary tests are good. The approach to the problem is shown in this article, in section V. Any person willing to go down to the solution is welcome to contribute.

The ADC firmware should usually be compiled and uploaded with Arduino IDE + Teensyduino. It would be lovely to upload the firmware directly to the ADC. That will provide a way to render operative the unit without Arduino IDE nor Teensysuino installed on the machine.

All the files on the SD are now dated the 1st of January 2000.
We must modify this behavior, adding the correct timestamp to each file.

It is possible to set up ADC initial configuration by mean of a text CFG file write on the microSD.
Within the file, that's the fun part; it's possible to use the same commands available during normal operation mode.
It's nice to post an article on the main site that shows usage and zero offset calibration.

ISAAltitude reported at 90000 Pa is more than 20000 m.

Check this page
http://www.azcloudflyer.com/flight_test/drag_polar_3.pdf
It should be nice to use also the angle of attack measurements.

File layout 1
https://github.com/BasicAirData/AirDataComputer/blob/master/Support/Brainstorming/Layout1.pdf
Source included

Layout 1 uses 5v amplified sensors. A dedicated IC performs analog to digital conversion for all sensors signals.
ADS IC had one SPI interface that is read by a Teensy 3.6 Board.
Cost of electronic components (- Teensy3.6) for airborne application is 310 Eur; bike application components cost 222 Eur
Total Nos. 6 sensors. 55 Eur static + 5X46 Eur DeltaP + 25 Eur ADS
(I will add an accessory voltage regulator soon)

Everything seems to fit together. However, there is an issue here. In the new system layout the Teensy board is disjoined from sensors board. That fact implicates that SPI bus should connect two board at a certain distance.

As you know, SPI is not able to cope with long connections.

Now the point.
Should we review the system layout or instead, let's say, fit a supplementary microcontroller near the sensors and equip the communication line with a RS 485 transceiver?

Cheers :-)

Reference Brainstorming URL:
https://www.basicairdata.eu/projects/air-data-systems/brainstorming-air-data-system-winter-2018-2019/

In firmware description, the altitude calculation is not shown.
Firmware
Needs to be added to "Compute Air Data" diagram.