Logiciels Libres (Freeware)

Le socle interministériel de logiciels libres (SILL) est un ensemble de logiciels libres préconisés par l’État français en 2016, dans le cadre de la modernisation globale de ses systèmes d’informations (SI). Sa gouvernance est réalisée par le Premier ministre sous trois grands principes :

  • L’approche de l’État privilégie l’efficacité globale, en dehors de tout dogmatisme, pour lui permettre de choisir entre les différentes solutions, libres, éditeurs ou mixtes.;
  • Pour chaque fonctionnalité, un logiciel est préconisé en précisant la version ;
  • La préconisation est évolutive dans le temps et elle fait l’objet d’une validation annuelle

En suivant ce lien, vous découvrirez la liste des logiciels libres de droit préconisés par l’état français. Ce sont essentiellement des logiciels orientés bureautique, business. Les makers ajouterons très probablement FreeCad (modélisation 3D) et KiCad (schéma, routage, bom, etc.) à cette liste !

La stratégie gouvernementale n’a pas toujours connu cette orientation. Bien que sous la même bannière, les militaires et les gendarmes avaient divergé dans leurs choix… Plus choquante fut la décision du ministère de l’éducation de s’allier à Micro$oft, une aubaine extraordinaire pour le géant informatique.

Je suis globalement en accord avec les propositions. J’y ajouterais volontiers Irfanview en tant qu’afficheur (et +!) d’images et FreeMind pour la gestion heuristique de projets.

TASCAM Sound Recorder (Part 5)

Part 1, 2, 3, 4, 5

As a professional equipment, the TASCAM DR40-X recorder features XLR inputs.

These are in fact combo inputs which are compatible with standard XLR connectors and 6.35 mm jack connectors . More important than the hardware, the electronics behind the connectors are very important. Most audio devices rely on unbalanced connections: the audio signal travels through one single wire. To prevent external interference, this wire is insulated and wrapped in braided wires which act as a shield. Although this method is satisfactory for short wires and standard use of audio devices, this shielding method is insufficient. The solution lies in the use of two wires for transmitting the audio signal: both wires conduct the same signal except that one is the negate of the other. This method is called the balanced mode.

Let’s see how it works with the example below:

First we start from a pure sine wave. The signal is split in two parts with same amplitude but one is negated versus the other. As they travel through the (twisted) wires, they are exposed to an unexpected burst. When the signal reaches the end of the cable, both signals are distorted in the same way. When the signal is ultimately reconstructed by adding one signal and the negated other, the burst is canceled.

Quality has a price: this method requires one extra wire, special 3 pins connectors and additional electronics. Splitting the signal and negating one is plain easy. However, this requires that some electronics is embedded in the source device along with its power supply. To prevent the use of batteries in small equipment (e.g. microphones), audio engineers had a bright idea: use the signal cable to transport energy to the source device. This energy must be a stable DC current which create a steady signal offset that we can null by means of capacitors. This power supply is called the “phantom power” as it exists but is invisible to the final listener.

Next picture illustrates the principle of the phantom power:

From right to left, a DC regulator feeds both signal lines through Re0 and Re1. At the receiver stage, Rr0 and Rr1 collect the voltage and use it to power the pre-amplifier.

The phantom power supplies comply with the CEI 268-15A rules. P48 used 48 V biasing through 6.8 k Ohm resistors, P24 used 24 V biasing through 1.2 k Ohm resistors and P12 uses 12 V biasing through 680 Ohm resistors

Then comes the problem of connecting a standard microphone to the recorder. Most microphones are electret microphones that require some biasing to operate. This biasing must be supplied by the phantom power thanks to an adapter. I chose the Rode VXLR+ adapter which is affordable (~25€), well made and looks like it can do the job.

The VXLR+ contains a small PCB which obviously care about decoupling the audio signal (thanks to the large 50 V capacitors) and some components for biasing the microphone.

This device worked perfectly well with commercial products as well as with my custom microphones.

Please note that the cheaper Rode VXLR does not contain any electronics and acts as a simple hardware adapter as shown on the picture below:

Next is a set pictures illustrating the various pin-outs involved in audio connectors:

Pinout of XLR connectors, view from the protuberant pins (male connector):

Pinout of jack connectors (3.5 mm) are specified by their number of rings, using the initial “T” for tip, “R” for ring(s) and “S” for sleeve. Next connector is a TRRS type

Various combinations exist which use jack connectors:

  • OMTP standard: T=audio left, R1=audio right, R2=microphone, S=ground
  • CTIA standard (apple): T=audio left, R1=audio right, R2=ground, S=
    microphone
  • Mono microphone: T=microphone, S=ground
  • Stereo microphones: T=microphone left, R=microphone right, S=ground

HTH

3D prints: Stevenson screen

Building a basic weather station today is simple and cheap thanks to specialized integrated circuits featuring temperature, humidity and pressure sensing. Up to now my favorite is the Bosh bme280; you may easily find it ready for use on small PCBs, easy to connect on any prototyping platform. Adafruit industries is selling a very convenient shield PID: 2652

Running this nice shield is really easy. However, turning it to a real weather station is another story. No need to be a professional meteorologist to guess that leaving this outdoor module “as is” will lead to inaccurate readings and rapid degradation. We just need a proper shelter, a so-called Stevenson screen. This enclosure must leave enough space to place the sensor and break the sun’s rays as well as the wind flow. Here is a proposal for a compact Stevenson screen printed in several stackable parts.

The lower stage features a stand for the shield and two screws, a hole and a grove for the signal cable and two hexagonal carvings for a pair of nuts to be used with mounting screws.

Next stages feature a Z shaped cross section

Then come a top sealed stage and the final cover stage. The air space between these two last stages acts as a thermal insulator against direct solar radiation.

 Download the STL files > here <

Enjoy!

Let’s celebrate Apollo XI !

I remember very well the 20th of July 1969… I was in a holiday camp and the director had the bright idea to get a portable TV set, to power it with the battery of his car and he managed to have as many kids as possible watching this event. At this time, I had no idea at all about what was happening, which were the roots of this project and which would be the consequences.

The image on the the TV screen was no better than my illustration, but god, that was almost incredible !

Years after, I discovered programming science through the use of hp 25 pocket calculators. These calculators were coming with the fabulous (at this time) lunar module landing game ! (More about this program). And a few years later, I joined hp and I got a calculator for free !

So I had the idea to clone this program on arduino just for fun !

I made it plain simple so that anyone can have some fun with it. When the game starts, you are 1000 m above the lunar surface, the LEM (Lunar Excursion Module) speed is 10 m/s, the fuel tank contains 150 arbitrary units while the moon gravity is 1.62 (1/6 compared to the earth gravity as you may know). Because the LEM is inexorably attracted by the moon, you need to fire the engines in order to decrease your downward speed and land at a speed equal or lower than 1 m/s …

To run the game, once the code has been uploaded, open the console and either repeatedly use the “Enter” key from your keyboard or use the button that you will attach between pin 2 and ground (or pin 2 and 3 like I did).
Next is the code. Again, plain simple:

/* 
Lunar module landing game
Didier Longueville July 2019
*/

/* LEM variables */
const float _gPerFuelIUnit = 2.0;
const float _maxLandingSpeed = 3.4; 	/* eq to a freefall of 12 feet */
const float _initialSpeed = 10; 		/* m/s */
const int16_t _initialDistance = 1000;	/* m */
const uint8_t _initialFuelLevel = 150;	/* liters */
/* application variables */
float _speed;
int16_t _distance;
volatile uint8_t _fuelLevel;
uint8_t _lastFuelLevel;
/* timing variables */
const uint32_t _intervalMs = 500; 	/* in ms */
const float _intervalSec = (_intervalMs / 1000.0); /* in s */
uint32_t _lastTime; 				/* in ms */
/* constants */
float _lunarGravity = 1.62; 		/* lunar gravity m/(s*s)*/
/* hardware */
const uint8_t _interruptPin = 2;
const uint8_t _groundedPin = 3;
volatile bool _preset = false; /* this variable MUST be volatile because of its insertion with the ISR */


void interruptService(void)
{
	/* read button state and set state (GND true) */
	uint8_t state = (digitalRead(_interruptPin) == LOW);
	/* apply some debouncing using kind of flip-flop */
	if (state && !_preset)
	{
		_preset = 1;
	}
	else if (!state && _preset)
	{
		_preset = 0;
		if (_fuelLevel > 0) 
		{
			_fuelLevel -= 1;
		}
	}
}


void initGame(void)
{
	_speed = _initialSpeed;
	_distance = _initialDistance;
	_fuelLevel = _initialFuelLevel;	
	_lastFuelLevel = _fuelLevel;
}


void setup(void)
{
	Serial.begin(38400);
	Serial.println();
	initGame();
	/* init the "fuel trottle" pin */
	pinMode(_groundedPin, OUTPUT);	
	digitalWrite(_groundedPin, LOW);
	pinMode(_interruptPin, INPUT_PULLUP);	
	attachInterrupt(digitalPinToInterrupt(_interruptPin), interruptService, CHANGE);
	Serial.println("New landing...");
}

void loop(void)
{
	uint32_t now = millis();
	uint32_t elapsedTime = (now - _lastTime);
	if (elapsedTime >= _intervalMs) 
	{
		/* compute */
		uint8_t fuelConsumption = (_lastFuelLevel - _fuelLevel);
		float gamma = (_lunarGravity - (fuelConsumption * _gPerFuelIUnit));
		_distance -= (((0.5 * gamma) * (_intervalSec * _intervalSec)) + (_speed * _intervalSec));
		if (_distance < 0)
		{
			_distance = 0;
		}
		_speed += (gamma * _intervalSec);
		_lastFuelLevel = _fuelLevel;
		/* display variables */
		Serial.print("s: ");
		Serial.print(_speed, 1);
		Serial.print("   d: ");
		Serial.print(_distance);
		Serial.print("   f: ");
		Serial.print(_fuelLevel);
		Serial.println();
		if (_distance == 0)
		{
			if (_speed > _maxLandingSpeed)
			{			
				Serial.println(">>>>> CRASH ! <<<<<");
				while(true);
			}
			else
			{
				Serial.println("--- You made it ! ---");
				while(true);
				
			}
		}
		/* timing stuff: record last event time */
		_lastTime += _intervalMs;
	}
	if (Serial.available()) 
	{
		while (Serial.available()) 
		{
			Serial.read();
			if (_fuelLevel > 0) 
			{
				_fuelLevel -= 1;
			}
		}
	}
}

All in all, this code contains a few ideas for debouching without a timer (and thus not suspending operation to the button release) and timing the computing function.

Enjoy !

Date and time serial: how to bypass the lack of precision of floats

Data type is probably the first concern for any new programmer in c/c++. These language require in minimal knowledge about integers and floats (Check this thread). Although these data types look familiar to all educated people, the principle of significant figures, which should be the universal way of formatting data, is, most of the time, ambiguous, foggy, unsure, etc.. Pocket calculators are mainly responsible for this lack of understanding; at the time of slide rules, who would bother about the nth precision digit and carry these insignificant figures over a bunch of operations ? Nowadays, most students are happy to copy the full content of their display as the result of operations which lead to express physical measurements with quasi unit-less figures.

Back to to the world of 8 bits controllers, the range and precision of floats must be taken into account and results shall be carefully interpreted before releasing a code. As I was recently working on RTC drivers and applications, I faced the need for exporting time-stamped logged data to a PC based application.

The best idea I could find to express absolute date and time consists in using the “Microsoft” – nobody’s perfect – date and time serial. This float is made of an integer part which represents the number of days since the 1 Jan 1900 at 0:0:0 (date serial 1 because of the Lotus-1-2-3 bug which was agreed by Excel for compatibility reasons !); the fractional part is a fraction of 1 day, so as to say 1 s = (1 / 24 * 60 * 60). Using these rules, it is right now 43604.685417 and that’s a lot more precision than the float data type can handle. However, sticking to serial date and time makes a lot of sens as converting the serial in MS EXCEL or compatible spreadsheets such as LibreOffice Calc, is as easy as: year(A1) & “-” & month(A1) & “-” & day(A1) & ” ” & hour(A1) & “:” & minute(A1) & “:” & second(A1), with the serial data and time in cell A1.

The trick I used is rather simple: firstly, I recorded the date serial as a 32 bits integer (16 bits suffice if your are short in memory) and the time serial in a 32 bits float. Then I reconstruct the full data and time information for printing and exporting to an application which can handle doubles. Next is the simple function which concatenates both serials:

/*
concatenate a 32 bits integer with a fractional 32 bits float to print a date 
and time serial (iiiii.ffffff)
*/
void printDateAndTimeSerial(uint32_t date, float time)
{
	/* create char array buffer */
	char *ptrArray = (char*)malloc(11 * sizeof(char));
	/* convert the integer part in a char array */
	ptrArray = utoa(date, ptrArray, 10);
	/* create char array buffer for the float conversion */
	char *ptrFloat = (char*)malloc(8 * sizeof(char));
	/* convert the float in an char array */
	ptrFloat = dtostrf(time, 8, 6, ptrFloat);
	/* copy the fractional part of the float, including the decimal separator */
	memcpy(ptrArray + 5, ptrFloat + 1, 7);
	/* print result */
	Serial.print(ptrArray);
	/* free memory space */
	free(ptrArray);
	free(ptrFloat);
}

HTH

Checking clock accuracy

This T&T explains how to check the accuracy of a Real Time Clock (RTC). Lets make it a little bit harder and say that you do not have access to the Internet…

Checking a RTC requires a highly accurate reference time base which can be read from a radio signal. Starting from there, two options are available: read the DCF77 radio signal, or the time stamps from a GPS receiver !

DCF77 is a German longwave time signal and standard-frequency radio station delivering a timestamp sent Coordinated Universal Time (UTC)+1 or UTC+2 depending on daylight saving time. Many, not to say most synchronized clocks and even watches read the DCF77 frames. The DCF77 frames feature:

  • Current date and time bits
  • Leap second warning bit
  • Imminent change of CET to CEST, or vice versa, Announcement bit
  • Central European Time (CET) / Central European Summer Time (CEST) bit
  • Abnormal transmitter operation identification bit
  • Several parity bits

Some restrictions must be taken into account: the radio signal may be disturbed and the emitter experiences some downtime over time (0.05 % downtime).

Many cheap (< 10€) receivers are available on the market such as this one below

As usual, the arduino community makes some nice code available

An alternate option consists in reading the time stamps from a GPS receiver. GPS receivers output a 1PPS (1 pulse per sec) signal which is to be used for synchronizing the timestamps readings using the BWC, GAG, GLL or the RMC sentences from the NMEA standards. Use the ZDA sentence to get the local time. The GPS time is as accurate as 40 ns, which far enough for my own needs.

I built a simplistic prototype to evaluate the Maxim-Dallas DS3231 RTC (datasheet).

After 4 months of continuous operation, after exposing the prototype to marge temperature changes (up to 20°C), I have been able to notice a 3 seconds shift which is better than the specification of the RTC (2 ppm @ >0°C and <40°C). which turns to less or equal 1 minute per year. In this way I managed to get a rough idea about the drift over 2, 5 or 10 years which represent the typical time scales for the IoT projects.

HTH

Code documentation (Part 1)

Part 1

Writing code is awesome. Have you ever compared coding works to the work of the potter ? He starts with a piece of clay, shapes it , refines it up to the final object. None from its production is fully identical to an other. Same thoughts apply to the coding works: the language is potter’s wheel, the bits, instructions, functions are the clay and the application is a plate, a jug, a vase. And we all know that we have our tricks, our fads, so that none from my code compares exactly to my colleagues.

As far as creativity is concerned, every thing is fine . However, the side effect of this statement relates to the documentation. As my own thoughts change along the time, my coding skills evolved too probably so that I am now confused when I get back to dated code which lacks critical documentation. I can remember very well a pretty tricky coding section that I worked on 8 years ago, that was so trivial to me at this time so that I did not document it exhaustively (apart from the basic standard line commenting). It took me an hour or two to reverse engineering this code up to the ascertainment that this was just a nice trick and not so much rocket science, however tricky enough to require some more comments.

Now that I handle x00.000 lines of code (actually 800 Mb of VB.NET code and 400 Mb of c/c++ code), documentation becomes quite critical. I paid a particular attention to my c/c++ libraries which are the fundamental basis for most of my applications and I decided to put some efforts on documenting my code, and improving the global description of the code in order to ease the use of these libraries and their inclusion in application code.

I searched the net, asked my colleagues about the de facto standard application for documenting c/c++ code and looked at what others did when writing code. In the end, Doxygen appeared to be the application I was looking for. The quite nice thing about Doxygen is its ability to run apart from the code (as long as you pass the proper parameters); most IDE’s feature optional plugins including Doxygen plugins, more or less sophisticated which help a lot in documenting the code, extracting the information and building the documentation files (html, chm and latex actually). The rules are quite easy to understand, quite flexible, and once again, you can write your comments and documentation blocks the way you like.

Here are a few links to Doxygen:

Video of the day

I love these highly risky rescue operations !

They remind some blood icing situations and the immense joy of saving a bunch of critical bytes of data or restarting a critical equipment just in time. Any story to share here ?

Best wishes for 2019 !

For the first time since 1993, we welcomed the whole family at home ! Including my dear Mom, 87 years old, a tonic Grandma, now a Grand-Grandma for the third time who agreed to travel with the tribe for this event. She paid a visit to my secret lab and asked many many questions and had a look at all these couloured bits and pieces pell-mell on my desk that she found “pretty”.

Well, I guess we have a new geek in town…

I hope you had a pleasant Chrismast time too, and I send my best wishes to you all.

3D Printing (Part 14)

Part 123456789101112, 13, 14

The heating plate is made of two symmetric printed conductive layers ~1.5 Ohm each. As printed on the heating plate you may wire them for use with 12 V or 24 V power supplies. As we need to add an extra power supply the choice for a 24 V power supply is trivial as less current will flow through the switch and the wires. As the minimum power rating for the power supply is 192 W, a 200 W power supply (and above) will do the job without efforts.

Nota: When choosing the power supply, check for the thickness. Many power supplies are 50 mm high which will prevent a proper cooling because of the insufficient air gap below the power supply.

This is the power supply that I bought:

  • Voltage in: AC 110 V/220  v
  • Voltage out: DC 24 v
  • Current out: 0 to 10 A
  • Weight: 0.5 kg
  • Dimension: 165*99*39 mm
  • Enclosure: alumina
  • Protections: over voltages, over-currents, short-circuits
  • Operating temperature: 0 to 40°C
  • Humidity: 0 to 95%

For a few euros I went for an off the shelf power switch. I found no reason why I should spend time to built a more expensive one.

This switch is driven from the heat bed output of the Marlin board. The switching part is fully isolated with an optocoupler. The marked wire is the goes to the + terminal on the main board.

Next picture contains the schematics of the Marlin main board where I circled the heater control output and the temperature input:

Best is to use MTA-100 series connectors (1 x 2 pins and 1 x 4pins). However if you do not not have such connectors you may use headers as the pins spacing is 2.54 mm.

Nota: the wire gauge is so high (in other words, the wires are so thin) that I failed to crimp the wires in the connector so that I add to solder the wires in order to achieve a reliable connection.

Next pictures illustrate the configuration that I choose for installing the power supply and the switch. The idea was to keep the wires as short as possible and to leave the aperture unmasked as I find it very convenient for cleaning the cabinet.

Save a sufficient cable length so that the wires will not suffer from being twisted back and forth down to breakage. Check my suggestion in the next picture:

Before connecting all pieces together, check the power supply voltage

and the heater resistance

Before running any print, you need to update the slicer parameters.

Go to the Cura pane, click on the Filament pane and set the appropriate temperature: 50°C (more or less) for PLA and 100°C (more or less for ABS)

Then you might want to update the G-Code which is executed prior and after printing:

Start G-Code

g28 ; home
g90 ; absolute positioning
g21 ; set units to mm
g0 z5 f5000 ; extruder above bed
g0 x150 y15 f10000 ; move fast to front right
m190 s{BED} ; set extruder 0 temperature and wait for it
m109 s{TEMP0} ; set extruder 0 temperature and wait for it
g0 z0.2 f500 ; up tray (slowly)
g92 e0 ; reset extr length
g1 e10 f50 ; feed filament
g92 e0 ; reset extr length
g1 x50 e10 f500 ; print wire
g92 e0 ; reset extr length

This start G-Code feature a short print which allows a proper priming of the extruder, a nozzle cleaning and a simple printing quality check.

End G-Code

g0 z180; down tray
g91; Relative positioning
g1 e-1; retract filament
m104 t0 s0; switch off extruder temperature
g90; Absolute positioning
g92 e0; Reset extruder position
m140 s0; Disable heated bed
m84; switch off steppers
m107; switch off fan

And here we are at last !

I checked the heated bed with Xmas decoration. Thin stars (0.6 mm, so as to say 3 layers) were subject to wrapping. They are now perfect using the default 50°C bed temperature

Enjoy!