We would like to hear from you!

plaindsp_audio_kit

Dear visitor,

We are very pleased to welcome you at the Arduinoos blog and we would like to hear from you and to get your opinions about our future projects.

Could you please complete this 5-minute online survey to get to know you better ? Thanks for helping.

Best regards,

The Arduinoos team

Click here to start the online survey

3D Printing (Part 7)

Part 1234567

After many hours of parts design and many rolls of ABS fused in our Makerbot Replicator 2x, it is time to write a little review on this nice printer, just be before it comes obsolete because of the new announced Makerbot products.

The Replicator 2x is doing what it was supposed to do. It is definitely an experimental printer which means that it is a good basis for printing all sorts of parts, but it suffers from uncontrolled performances which result in many printing failures and big need for improvements in part design and parameter settings.

The most critical aspect of the Makerbot 2x is the temperature control of the whole printer. I do not even care about the mod applied to the extruders thermocouple which is, to my opinion, a straight design error more than an uncontrolled function. Printing a simple ruler, 2 x 2 x 15 cm illustrates very well the major flaw. In most cases, this type of print will fail because of corner warping. This is very frustrating phenomenon because it happens  late in the printing process which means a loss of ABS and and a loss of time.

I read here an there many comments and suggested tricks to overcome this problem: Use this brand for acetone, use this type of Kapton tape, rub the Kapton with sand paper, do not rub the Kapton, change the heated bed temperature, spit on the Kapton tape (Oh nooo) …

I personally identified two causes for this defect. One is the heat balance of the part, the other is more mechanical. My assumption is that both causes have approximately the same weight. As the heat balance is pretty complex to handle and would require significant mods to the printer, I suggest that we concentrate on the second cause.

Here are few points to keep in mind while tweaking these warping issues:

  • ABS does not have sticking properties. If it would, it would not flow through the heated extruder, would it?
  • Acetone does not have sticking properties, neither Kapton
  • Putting the top cover on or off as no effect on the warping. Except that printing large flat surfaces with the cover on will lead to filament drive problems.

So how come my part stick on the heated Kapton coated bed?

The absence of air between the Kapton surface and the ABS film deposit (in other words, vacuum) is responsible for the “sticking” of the part on the bed. It is the atmospheric pressure which pulls the part on the Kapton surface. Thus the following thoughts and hints:

  • The larger the printed surface, the more the force as F= P.S where F is the force applied to the part (in N), P is the pressure (in Pa/m^2, with atmospheric pressure = ~100000 Pa) and S is the (contact) surface (in m^2). For example, the atmospheric pressure will exert a force on a printed part which contact surface is 10 cm^2 identical to a weight of 10 kg. Adding mouse ears to the part corner increases the contact surface and thus the pressure exert on the part.
  • The better the surface of the bed, the lesser the air leaks. Scratches on Kapton tape will create the so called capillary leaks. Poor bed and nozzle adjustments will also lead to multiple air leaks because the ABS will be deposit as rolls and not as a layer.

I am currently experimenting and testing heavily an alternative technique which really solves elegantly and efficiently this question. However, I am immensely curious to see the new Makerbot Replicator printer. From the pictures on their web site, I clearly see a fan which indicates that the heat balance within the printing chamber as been reworked, probably with the hep of the Stratasys R&D people…

3D_printer

The contribution of  Stratasys to Makerbot is clearly visible on the announced Makerbot Replicator Z18 !

 

 

Gamer Assembly 2015

Welcome to the Gamer Assembly 2015 in Poitiers / France!

Quai Lab was in charge of leading the Maker Space. We invited various contributors to the word of open source, open hardware and open knowledge. Here are a few snapshots from the grand opening of the gamer by Désiré KOUSSAWO:

ga_2015_2

Quai Lab is on stage with Sébastien BONNIFET representing the association!

 

 

ga_2015_1

 

This is a great time for Quai Lab which grew up so quickly and so nicely. More news coming…

 

Drive the Small Cox

We will be happy to welcome you at the Maker Space within the Gamer Assembly in Poitiers next week-end. Next is the command pad which will give you a chance to drive the sound driven robot!

 

                           
Forward
                           
Left
Stop
Right
                           
Backward
                           

Meet us at the Gamer Assembly

HL2 group is now the team behind Arduinoos. We are very much involved in the development of local and national initiatives in the world of open data, open software and open hardware. The team co-funded QuaiLab a very active FabLab which has been selected for managing a Maker Assembly aside the now famous Gamer Assy.

ga2015-logo

So, you are mostly invited to …

meet_us_gamer_assy_m

… at the Gamer Assy.

This amazing small robot has been extrapolated from an idea raised at QuaiLab, featuring an Arduino UNO, PlainDSP, a pair or servo-motors, a printed frame, two o’rings and a bunch of screws! The robot is driven by tones generated by a cell phone, or by instructions from Arduino IDE console and it can record and replay the recorded path. A detailed description of this project will come soon after the show.

 

 

Tips and tricks (Part 23)

Previous T&T

Although the situation is not very common, you may face like me the following situation: I needed to read analog signals applied to some of the 6 ports from an Arduino UNO. But some of the readings would use the Vcc reference (so as to say the analogReference(DEFAULT))  and some others would use the 1.1 V internal reference (so as to say the analogReference(INTERNAL)).

Jumping from one reference to another is not without risks of getting very confusing analog measurements. Arduino reference manual says:

After changing the analog reference, the first few readings from analogRead() may not be accurate.

Good point, however how much is “few”? If you drop an eye on the ATMEGA 328 Datasheet, you may read that: “the user must allow the (internal) reference to start up before the output is used…. … Refer to ”Internal Voltage Reference” on page 51 for details on the start-up time.”

So far so good. And well, I decided that I would do something special to make 100% sure that my readings are correct, whatever the operating conditions. The best way to do that would be to use a reference voltage, attach its output to a dedicated analog port and perform measurements as long as the gap between to consecutive measurement is not null. Although this option is bulletproof, it is expensive in terms of addtional components and commissioning of analog ports.

After some more reading in the ATMEGA data sheet, one can read at the MUX section that 6 among the the 14 theoretical ports are used by arduino, one (actually port 8) allows access to the chip temperature (the famous hidden thermometer) and another one (port 14) reads the internal 1.1 V! Hurray! We have a built in reference!

mux

Here is is the function that I wrote to perform the analog to digital startup. The comments in the code should suffice to explain the way it works.

void InitAdc(uint8_t ref)
{
	ADMUX = 0x00; /* Clear register */
	analogReference(ref); /* Set reference */
	analogRead(0); /* Read any channel once in order to set parameters */
	ADMUX |= 0x0E; /* Set channel 14 so as to say 1.1 V ref */
	const uint8_t ADSCmask = (1 << ADSC); /* Compute mask once to save time */
	/* Set comparison parameters */
	const uint8_t maxReadings = 100;
	const uint8_t maxDelta = 4;
	/* Local variables */
	uint8_t readings = 0; /* Readings prevent infinite looping */
	uint16_t lastReading = 0;
	uint16_t reading = 0;
	do {
		delay(1);
		readings += 1; /* Record readings */
		lastReading = reading; /* Record last reading */
		ADCSRA |= (ADSCmask | (1 << ADEN)); /* Start single conversion */
		while((ADCSRA & ADSCmask) == ADSCmask); /* Wait for conversion to complete */
		reading = (ADCL | (ADCH << 8)); /* Compute resulting adc counts */
	} while ((abs(reading - lastReading) > maxDelta) && (readings < maxReadings));		
}

HTH

 

 

Tips and Tricks (Part 22)

Previous Tip & Trick

Here is an update of the Electronics Pinout Sheets originally issued by Arduinoos and now edited by PlainDSP (same team behind the screen!)

elec_pinout_v4

HTH

Next Tip & Trick

 

Doppler Effect

Have you ever wonder why the sound from the honk of a car changes as the car travels next to you. While in the same time, the driver of this same car swears that the sound of his honk did not change a bit while he was sitting in the car! Who is right?

Well, have a look at this post and discover how the Plain DSP audio kit can help in solving this enigma!

Extremely Low Frequency Electro Magnetic Field Sensing (Part 5)

Part 1234, 5

Time for upgrade. The pretty popular ELFEMF posts were prepared before the obsolescence of PlainADC and PlainFFT libraries.  Next is the revised code for the detection of Extremely Low Frequency Electromagnetic Fields which is compatible with PlainDSP library. So simple and yet powerful application! Enjoy.

/*
 
	MicroELF_EMF: Electrical radiation measurement
	Revision 03

	Applicable license :

	This program and related documentation are owned by HL2 group SAS. 
	The program is subject to the license GNU GPL version 3. This license 
	allows you to use, reproduce and adapt this program for private, 
	educational, research purposes. 
	
*/

#include <PlainDSP.h>

/* Create objects */
PlainDSP DSP;

const uint8_t ctrlLedMask = (1 << PINB5);

/* Acquisition parameters */
const uint16_t _samples = 128; /* Max value depends upon available memory space */
const float _samplingFrequency = 400.0; /* From 0.125 Hz to 80 kHz */
const uint16_t _adcChannel = 0; /* From 0 to 5 on ATmega328 powered Arduino */
const uint16_t _refVoltage = DSP_REF_VOL_INTERNAL; /* Internal: 1.1V */
const uint8_t _options = (DSP_OPT_DIS_TIM_0 | DSP_OPT_DIS_TIM_2 | DSP_OPT_NOI_CANCELLER);
/* Display parameters */
const float _targetFrequency = 50.0;
const float _frequencyTolerance = 5.0;
const uint16_t _maxOnTime = 600;

void setup(void)
{
	/* Initialize serial comm port */
	Serial.begin(115200); 
	/* Set data acquisition parameters */
	DSP.SetAcquisitionEngine(_adcChannel, _refVoltage,  _samplingFrequency, _samples, _options);
	/* Init control LED */
	DDRB |= ctrlLedMask;
}


void loop(void)
{
	/* Acquire data from selected channel */
	DSP.GetScanData(); 
	/* Null offset */
	DSP.ResetOffset();
	/* Weight data */
	DSP.Windowing(DSP_WIN_TYP_HANN, DSP_FORWARD);	
	/* Compute FFT */
	DSP.ComputeForwardFFT();	
	/* Compute amplitudes */
	DSP.ComplexToReal(DSP_SCL_TYP_AMPLITUDE);
	/* Find target peak */
	struct strPeakProperties targetPeak;
	DSP.TargetPeak(_targetFrequency, _frequencyTolerance, &targetPeak);
	/* Compute blink on/off ratio */
	uint16_t onTime = uint16_t(targetPeak.height);
	if (onTime > _maxOnTime) {
		onTime = _maxOnTime;
	}	
	uint16_t offTime = (_maxOnTime - onTime);
	/* Control LED */
	PORTB |= ctrlLedMask; /* Toggle control led on */
	delay(onTime);
	PORTB &= ~ctrlLedMask; /* Toggle control led off */
	delay(offTime);
	/* Optionally print data */
	// Serial.print((millis() / 1000.0), 3);
	// Serial.print(';');
	// Serial.print(targetPeak.height, 2);
	// Serial.println();
}

Reminder: Just insert the bare end from a piece of insulated wire (~20 cm long) in the analog port 0. Power the arduino board, upload the code. The internally built LED (Digital port 13) will blink according to the magnetic field strength… The closer you get from an AC line or a power distribution point, the longer the on state of the LED.

Warning: Do not touch live power lines, sockets or equipment with the wire!

 

 

Bug Of The Day

And this is a strong one!

We are using quite many UNO platforms for fast prototyping. In spite of their relative high price, we always bought boards from Arduino, not because we fear the ‘hall of shame’, but because we understand that that buying these boards contributes to the business model of the Arduino team and helps keeping the heads of this community alive.

So far so good, except for today. We received 6 UNO boards that we bought from FARNELL which is our main supplier. And too bad, only one out of the six boards was working properly!

Connecting a ‘defective’ board through the USB port would systematically trigger the following message:

uno_usb_pb_01

A known for good board would immediately be recognized, whatever the type (UNO, MEGA, etc.). So what? From the beginning, our assumption was that the firmware on the ATMEGA 16U2 (this little square chip next to the USB port) was corrupted, and we were right! The ATMEGA 16U2 acts as a converter between the USB port and the Serial Communication Port of the microcontroleur (so as to say the ATMEGA 328). It holds some firmware which cares about the conversion.

Upgrading the firmware on the ATMEGA 16U2 is fortunately piece of cake if you follow the next coming instructions:

  • Make sure that you run the latest version of Arduino. The IDE has nothing to do with the described action, however, the latest software versions contains the most update drivers.
  • Download and install the FLIP software from the ATMEL web site (freeware, no registrations). Here is a link with the FLIP page. My version was 3.4.7.
  • Open the device manager and locate the ‘defective’ UNO (My PC is running Windows 7 pro, 64 bits)

uno_usb_pb_02

  • Shortcircuit the two pins from the ICSP connector for a few seconds. The UNO board is now recognized as

uno_usb_pb_03

  • Update the driver for this newly created device: double-click on ‘ATmega16U2′, select the ‘Driver’ tab and click on ‘Update Driver…’

uno_usb_pb_04

  • Click on ‘Browse my computer for driver software’

uno_usb_pb_0(

  • The drivers are located in ‘C:\Program Files (x86)\Atmel\Flip 3.4.7\usb’, click on the ‘Next’ button

uno_usb_pb_06

  • Done! Now run the FLIP application

uno_usb_pb_07

  • Select ‘ATmega16U2′ in the device list

uno_usb_pb_09

  • Select ‘USB’ in the ‘Communication’ ‘Settings’ and open the USB port

uno_usb_pb_10

  • Load the HEX file from ‘C:\Program Files (x86)\arduino-1.6.0\hardware\arduino\avr\firmwares\atmegaxxu2\arduino-usbserial\Arduino-usbserial-atmega16u2-Uno-Rev3.hex’ and check the ‘HEX file aprsed’ message in the status bar.

uno_usb_pb_08

  • The FLIP main window looks like this:

uno_usb_pb_12

  • Click on the Run button, and here is the updated window of FLIP showing successful execution of the Erase, Blank Check, Program and Verify actions.

uno_usb_pb_13

  • Unplug the Arduino board and plug the USB cable back. The Device Manager shows an ‘Unknow device’ for a little while, finds the driver and finally adds the Arduino board to the list of Ports (COM & LPT)

uno_usb_pb_14

  •  If your computer fails to self recognize the Arduino board, go through the standard procedure for upgrading the Arduino driver.

 

HTH