What good designs are available for Geiger counters using an Arduino?

There are a few good, open-source, designs for Geiger counters using cheap G-M tubes and Arduino boards out there. Which one is best for you depends on what you want to achieve, so let's start by taking a look at what you might want to detect.

What are these "types" of radiation?

(source: Wikipedia)
Alpha radiation: basically consists of helium-4 nuclei (i.e. two protons and two neutrons). These interact with matter strongly because they are relatively heavy and carry a positive charge. However, because of their mass they will normally only penetrate a few centimetres of air. Alpha particles can be stopped in their tracks by a single sheet of paper.
You may not realise it, but the sensor in most smoke detectors uses a very small amount (~0.2μg) of Americium -  241Am.

Beta radiation: consists of highly energetic electrons. Because these particles are relatively light, they can penetrate somewhat further than Alpha particles. Even so, beta radiation can be stopped by a thin sheet of aluminium.
The big risk to human health from alpha- and beta-emitters is when they are ingested or inhaled. In these cases, the particles are brought into close contact with sensitive live tissue where the ionising radiation has the potential to cause various types of cancers.
Gamma radiation: is electromagnetic radiation having a higher frequency and shorter wavelength than X-rays.

One way to think of gamma-radiation is like a kind of "super X-ray". Gamma rays can pass through virtually anything. To build an effective shield, you need to have either very thick walls or a shield made from something with a high atomic weight, such as lead.
Gamma rays are produced naturally by the sun and stars - this is the source of what we call "cosmic radiation".

So which tubes should you choose?
Once you have decided what types of radiation you want your Geiger counter to detect the next step is choosing the tube. In general, they are all high-voltage tubes, typically operating at ~ 400V.
At the moment, the cheapest available tubes are probably the Russian SI-3BG Geiger Muller tubes, which can be picked up on eBay for about £5 GB. These are not very sensitive, but I've found they do work OK for beta and gamma radiation. However, it doesn't detect alpha radiation (which, as mentioned earlier, is what is emitted by the source in the sensor in many smoke detectors!)
One thing to watch out for is that these tubes are all different sizes, ranging from about 20mm long to more than 200mm. This matters. If you are going to design or buy a PCB for your project, just check that it has been designed to fit the sensor that you intend to use.
The following table lists the most popular G-M tubes, together with their main characteristics:

Follow the links below for further data on each tube:

SBM-20
SBM-21
SI-1G
SBT-9
SI-3BG
LND-712
LND-7124
LND-7224
J408γ
J305β
J306β

Your choice of tube is going to be determined by your budget, the types of radiation you want to detect and the sensitivity you want to achieve with your G-M counter.

Circuit designs
OK, so now we understand the radiation types, and we've chosen our tube, what Geiger counter designs are out there that use the Arduino.
(disclaimer: I have no connection with any of the companies mentioned in this answer)
Well, it turns out there are a few good designs out there (Google is your friend here), but one that does stand out from the pack (IMHO) is the Geiger Counter - Radiation Sensor Board for Arduino and Raspberry Pi from Cooking Hacks.
This is an open hardware design, and the code can be downloaded on a GPL licence.
It's a relatively simple design, and has a kit available pretty much off-the-shelf. Software can be downloaded for the Arduino and/or the Raspberry Pi. If you decide to buy the kit, they assure us that the shield/hat has been tested with the Arduino Uno and all models of the R-Pi.
Alternatively, you can just download the circuit diagram on the link above and design your own PCB (I don't think they offer the Gerber or Eagle files to download).
It is worth mentioning that the tutorial page also includes all the lovely useful background theory you'll need to understand how Geiger counters work, and how to get the most out of it.

Final thoughts. If you were thinking of building a Geiger counter without using an Arduino (Yes, yes, I know. But there may be some strange people out there who want to go this route!), there are still some nice designs out there you can play with.
The Geiger counter from MightyOhm is also open-source and uses the SBM-20 Geiger-Muller tube. Again, it is available as a kit, but if you prefer the DIY route, the design files are available to download.
Having looked at it, adapting this design to interface with an Arduino would probably also be relatively straightforward ...
If you are on a really tight budget there is a $15 Geiger counter on Hackaday. This uses the Russian SI-3BG G-M tube (discussed above) and a modified power-supply from a disposable camera.
I built one of these with a friend who was just starting out studying electronics and wanted to have a go at this project. I can confirm that it works, but that $15 price-tag is very optimistic.
(Having built this one, my friend decided that her next project would be to design a better one with greater sensitivity and which could detect alpha-, beta- and gamma-radiation and which incorporated an Arduino Uno. In hindsight, I should probably have mentioned the design from Cooking Hacks ..!).


Can you save data to heap section in Arduino memory?

Yes, you can use malloc() on the Arduino - however it is not something I would recommend you use since memory is at a premium and excessive use of malloc() and free() causes heap fragmentation which can eat your memory up and cause random crashes (String is the biggest culprit of this).

I am not sure what you mean by "clean" the memory.  When power is removed the content of the memory is lost. The whole of the SRAM forgets its contents if there is no power to maintain that state.  A bit like when you unplug your computer it "forgets" that Windows is loaded.

If you want to retain information with the power removed you need to use the EEPROM.


The voltage level fluctuates whenever ESP8266 receives signal

The ESP8266 is notoriously noisy, chiefly because the cheap boards the ESP8266 is commonly sold on don't implement any form of power filtering.

So you really have to add your own.  As I had to recently when adding an ESP8266 board to an audio system.

For that I came up with this schematic:

VCCA is your main incoming power.  VCCD feeds the power into the ESP8266. The motors are connected to the same point as VCCA.


This is more of a Stack Overflow question, but I'll help you a bit. The problem has nothing to do with your Arduino per-say. It has more to do with your PHP/Ajax.

Your code is suited for a completely local setup, but pulls from a remote site, which violates some security protocols build into your browser and jQuery. You need to change your code to this:

$.ajax({
    url: 'http://192.168.1.177/',
    type: 'post',
    data: { tag: 'getData'},
    dataType: 'jsonp',
    async: false,
    success: function (data) {
        $('#TemperaturaInterior').val(data.TemperaturaInterior).show();
        $('#TemperaturaExterior').val(data.TemperaturaExterior).show();
        }
    });
(may need slight modifications since you didn't include all PHP/html code)

For more information, see the jQuery documentation, particularly look at data types and what it says about cross-domain json vs jsonp.

Here is a relevant SO question.


Stepper motor based clock movement with DS3231

It is unclear, why you need the high accuracy, and you didn't include your code. So my explanations will be as broad as your question.

"millisecond resolution" is a broad term. Generally you have to consider 2 different errors.

The jitter for every millis() value
clock drifting over time

You can eliminate the second point quite easily using the RTC with the Time library. It uses the RTC as a reference, so that you don't have the clock drifting this much. Though, you would have to use the libraries functions for all time related things, since it does not change the value of millis() or it's siblings.

Also, for low differences in the range of a few milliseconds, you should better use micros() instead of millis() (if you are not using the RTCs functions).

  How would you then translate that output to pulses sent to the stepper motor driver board?

It is unclear, why exactly you need "millisecond resolution", and you didn't show us your code. But there are multiple Stepper libraries on the web, for example the standard Stepper library or the AccelStepper library (Accelstepper is more capable, don't know, if you need it). With the AccelStepper libraries you can set a certain speed and target position and then you simply call then run() method (haven't looked up the name, but there is definitely a function like that) until the desired position is reached. The method itself will only pulse the stepper, if it is time to do so. So you are freed from doing all the stuff with millis(), since the library is doing that for you.

Though the libraries are using the Arduinos internal time: millis() and siblings. To change that, you would have to change the library.


Yes, it should work. The HX711 need two pins each (one for clock and one for shifting out the data). The MPU6050 seems to have an I2C interface, which needs two lines (SCL and SDA). And lastly an ESC uses a PWM pin.

All in all this needs 7 pins, way less than an Arduino UNO has.

Note that having enough pins doesn't mean, that you can usw all the sensors at the same time. You might habe to disable one for a short time to do something else.


Saving library example sketch getting error "you cannot save a sketch into a folder inside itself.."

What I normally do is make the examples in their own folders (ie. inside the sketchbook folder). Then when they are tested I just use the file system to move the folders into the "examples" folder under the library.

  When I do that, and try to save my LightBrightMain.ino file into /devel/arduino/libraries/LightBrightLib/examples/LightBrightMain/,

The IDE makes the folder, so you would (if this works at all) save LightBrightMain into the examples folder. Don't make a folder of the same name as the sketch. The IDE does that.


Porting ATMega8 AVR based program to Intel Curie Processor

Those variables are the addresses of physical registers on the AVR that manipulate its timer/counters. Most other processors will have equivalent, but not likely identical, hardware. You'll need to port functionality, not the code.

You'll need to reverse-engineer (worst-case) the code you're trying to port (assuming you aren't intimately familiar with it, e.g., you designed it), develop a spec for it (at least in your head), and write to that spec for the Curie.

If the overall job is not (too heavily) processor-specific, you may be able to write it to be portable by writing the job-specific code in, e.g., in C, and call well-defined functions (in C or assembler) for the CPU-specific ones, that could easily be replicated on another processor.


How do I calculate sampling rate of external ADC?

Easy.

Based on your set up, figure out the spi speed.
Take a look at the adc datasheet, figure out it's frame of transmission . Aka how many pulses per frame / sampling.
The product of the numbers in 1 and 2 gives you the minimum time per frame. The inverse of it is the maximum transmission in your application. That speed is cap by the devices own max sampling rate (100ksps).
Your actual sampling rate will depend on your specific application but it should not go above the number obtained in 3.
You may need to factor in other timing requirements as well so read the datasheet carefully. But the gist is the same.


Your first problem is here:

char ReadKeypad(){
  if(button1.isPressed() && !button2.isPressed()){
    return 'D';
  }
  else if(button2.isPressed() && !button1.isPressed()){
    return 'U';
  }
  else if (!button1.isPressed() && !button2.isPressed()){
    return 'N';
  }
  else if (button1.isPressed() && button2.isPressed()){
    return 'S';
  }
}

The compiler gives a warning, which you should pay attention to:

In function 'char ReadKeypad()':
warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

The warning basically is that if no button is pressed you are returning an undefined value. It would be better to add to the end:

return 0;  // no button pressed

Then later on in page1 function:

  for (int i; i<16; i++){
    lcd.print(binary[i]);
  }

Another compiler warning:

In function 'void page1()':
warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
       for (int i; i<16; i++){

You haven't initialized i so it could have any value. That should read:

  for (int i = 0; i<16; i++){
    lcd.print(binary[i]);
  }

Ditto further down.

If I add some debugging here:

void MainmenuBtn(){
  btn_push = ReadKeypad();
  Serial.print ("btn_push = ");
  Serial.println (btn_push);
 // WaitBtnRelease();
}

And then press a button, I see:

btn_push = D
btn_push = D
btn_push = D
btn_push = D
btn_push = D
btn_push = D
btn_push = D
btn_push = D
btn_push = D
btn_push = D
btn_push = D
btn_push = D

So that is registering as many presses, not just one. You should test for "has the button state changed?". That is:

Is the button closed now?
Was it closed before?
If the two are different, then the button has just been pressed.

Adding debugging prints is very helpful in general when things aren't going to plan.

If you had added those extra prints to your MainmenuBtn function you would immediately have seen that it looked like the button was pressed hundreds of times (until you let go) rather than once.

  the position changes from 1 to 8 or 16 instead of to the second bit when I hit the right button

Exactly. Since it is treating a button press as a multiple press you would expect exactly that to happen. Effectively you have built in a very fast auto-repeat (unintentionally).

Edited to add:

Your code is so confusing I've rewritten the state change stuff.

#include <LiquidCrystal.h>
/*(RS, E, D4, D5, D6, D7)*/
LiquidCrystal lcd(12,11,5,4,3,2);
#include <Button.h>

int page = 0;
int binary[16] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
int con = 80;
char btn_push;
int pos = 0;

const int button1Pin = 8;
const int button2Pin = 9;
int button1State = HIGH;
int button2State = HIGH;
int lastButton1State = HIGH;
int lastButton2State = HIGH;

unsigned long debounceDelay = 50;

//****************************************************************setup*****************************************
void setup() {
  pinMode(button1Pin, INPUT_PULLUP);
  pinMode(button2Pin, INPUT_PULLUP);

  Serial.begin(9600);
  analogWrite(6,con);
  mylcd.begin();
  lcd.print("Welcome");
}

//************************************************************loop************************************************

void loop() {

  int reading1 = digitalRead(button1Pin);
  int reading2 = digitalRead(button2Pin);

  if (reading1 == lastButton1State &&
      reading2 == lastButton2State)
    return;  // do nothing if no change

  delay (debounceDelay);  // debounce

  // re-read so we can catch both buttons down at once
  reading1 = digitalRead(button1Pin);
  reading2 = digitalRead(button2Pin);

  // save for next time
  lastButton1State = reading1;
  lastButton2State = reading2;

  if (reading1 == LOW && reading2 == HIGH)     // first one down
    btn_push = 'D';
  else if (reading1 == HIGH && reading2 == LOW)  // second one down
    btn_push = 'U';
  else if (reading1 == LOW && reading2 == LOW)  // both
    btn_push = 'S';
  else
    return;  // nothing interesting

 Serial.print("btn_push = ");
 Serial.println(btn_push);

    // page select
    switch (page) {

    case 0:
      page0();
      break;
    case 1:
      page1();
      break;
    case 2:
      page2();
      break;
    case 3:
      page3();
      break;
    case 4:
      page4();
      break;
    }

}

// The rest is the same, excluding the functions that are no longer needed

I made the buttons INPUT_PULLUP so that they normally read HIGH if not pressed, thus LOW means pressed (therefore the switches should be wired from the digital pin on one side to Gnd on the other side).

It still isn't perfect but that should give you something to play with. Add some more debugging prints to see what is going on in the other functions.


While the ArduinoStarterKit page at arduino.cc lists “5 Diodes [1N4007]” as part of it, and has a picture where 5 diodes apparently appear slightly left of center in the top row, several other pictures that come up in a google images search for official Arduino Starter Kit apparently don't show the diodes.  Eg, as at arduino starter kit.  But 4 Best Starter Kits for Arduino Beginners does show them.

Note, unless you are working with medium to high AC voltages (eg above 50 V) you can substitute 1N4001 - 1N4004 which have lower PIV ratings but also slightly lower forward voltage drop.  For many beginning projects, 1N4148 signal diodes will be adequate and perhaps less expensive.


avrdude: stk500_recv(): programmer is not responding after serial

Likely all you really need to do is exit/kill every process trying to use the Arduino, un-plug it from the USB port, and plug it back in.

This is in part because Linux doesn't really block multiple programs from trying to use the serial device at the same time, unless they take particularly efforts to claim it exclusively, but the attempted sharing may result in serial traffic that doesn't make any sense.

Another issue can be that if a still-running program was using a device that vanished, when that device is reconnected it will not be assigned to the in-use port number, but to a free one.


Arduino UNO SPI Serial Clock (Pin 13 SCK) gives no output, but Blink Example (Pin 13 LED) works

I can't reproduce that. Using your first test code:

#include <SPI.h>

void setup() {
  //pinMode(13, OUTPUT);
  SPI.begin();

}

void loop() {
  SPI.transfer(0x00);
}

I get this on the logic analyzer:

Also on my scope on pin 13:

As expected, a 4 MHz signal with gaps between the bytes.

  I expected the clock to be high frequency and continuous for SPI.

No, you get the clock when data is being transmitted and not at other times.

  Although likely irrelevant to the question, I noticed some periodic 6us gaps every ~1ms on this UNO Pin 10 (MOSI) signal.

That would be the Timer 0 interrupt kicking in (roughly every 1 ms) and thus interrupting your looping code for a few microseconds.

Possible solution

Try enabling slave select (write LOW to pin 10). I think some versions of the logic analyzer ignore incoming data if the slave isn't selected.

In fact, pin 10 should be an output, otherwise the SPI hardware goes into slave mode. Some versions of the library might not set it to output.


Modifying Arduino IMU library to rely on DSSCircuit's I2C Master Library

You are missing the rest of the code in reading operations. You are just requesting the data, no actually reading it from the device:

the original code of adlx345::read

void ADXL345::readFrom(byte address, int num, byte _buff[]) {
  Wire.beginTransmission(_dev_address); // start transmission to device
  Wire.write(address);             // sends address to read from
  Wire.endTransmission();         // end transmission

  Wire.beginTransmission(_dev_address); // start transmission to device
  Wire.requestFrom(_dev_address, num);    // request 6 bytes from device

  int i = 0;
  while(Wire.available())         // device may send less than requested (abnormal)
  {
    _buff[i] = Wire.read();    // receive a byte
    i++;
  }
  if(i != num){
    status = ADXL345_ERROR;
    error_code = ADXL345_READ_ERROR;
  }
  Wire.endTransmission();         // end transmission
}

would change to (if no mistakes made):

void ADXL345::readFrom(byte address, int num, byte _buff[]) {
  I2c.read(_dev_address, address, num) // request 6 bytes from device
  if(I2c.available() != num){  // device may send less than requested (abnormal)
    status = ADXL345_ERROR;
    error_code = ADXL345_READ_ERROR;
  }

  int i = 0;
  while(I2c.available())
  {
    _buff[i] = I2c.receive();    // receive a byte
    i++;
  }
}

you may need to force cast parameters between functions.

If for some reason you don't want the actual code and want to use another library, I'll suggest I2Cdev site with a well documented classes for adlx345 and ITG3200.

Edit:

This caused me no problem. That is the only 2 functions I changed:

// Writes val to address register on device
void ADXL345::writeTo(byte address, byte val) {
  I2c.write((uint8_t) _dev_address, (uint8_t) address, (uint8_t) val);
}

// Reads num bytes starting from address register on device in to _buff array
void ADXL345::readFrom(byte address, int num, byte _buff[]) {
  I2c.read((uint8_t) _dev_address, (uint8_t) address, (uint8_t) num);  // request 6 bytes from device
  if(I2c.available() != num){  // device may send less than requested (abnormal)
    status = ADXL345_ERROR;
    error_code = ADXL345_READ_ERROR;
  }

  int i = 0;
  while(I2c.available())
  {
    _buff[i] = I2c.receive();    // receive a byte
    i++;
  }
}

Arduino code used:

#include <I2C.h>
#include "FIMU_ADXL345.h"

ADXL345 acc = ADXL345();
int x=0,  y=0, z=0;
void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);
  I2c.begin();
  delay(100);
  acc.init(ADXL345_ADDR_ALT_LOW);
  delay(100);
  Serial.print("Is ACC OK?: ");
  Serial.println(acc.status);
  Serial.print("Any Error code?: ");
  Serial.println(acc.error_code);
  Serial.println("********Print all register current values********");
  acc.printAllRegister();
  Serial.println("********END register print******");
  Serial.println(acc.getRate());
}

void loop() {
  // put your main code here, to run repeatedly:
  acc.readAccel(&x,&y,&z);
  Serial.print(x);
  Serial.print('\t');
  Serial.print(y);
  Serial.print('\t');
  Serial.println(z);
  delay(500);
}

Output given:

Is ACC OK?: 1
Any Error code?: 0
********Print all register current values********
0x00: B11100101
0x1D: B00000000
0x1E: B00000000
0x1F: B00000000
0x20: B00000000
0x21: B00000000
0x22: B00000000
0x23: B00000000
0x24: B00000000
0x25: B00000000
0x26: B00000000
0x27: B00000000
0x28: B00000000
0x29: B00000000
0x2A: B00000000
0x2B: B00000000
0x2C: B00001010
0x2D: B00001000
0x2E: B00000000
0x2F: B00000000
0x30: B10000011
0x31: B00000000
0x32: B11110101
0x33: B11111111
0x34: B00000011
0x35: B00000000
0x36: B11100101
0x37: B00000000
0x38: B00000000
0x39: B00000000
********END register print******
100.00
-12 4   230
-10 2   231
-11 3   231
-12 3   228
-10 3   230
-11 2   231
-12 2   229
-11 3   229
-10 3   231
-11 3   229
-10 2   230
-12 4   230
-12 3   229
-10 2   229
-13 4   230
-11 3   230
-10 3   230
-11 2   230
-11 4   229
-11 3   230
-11 3   230
-11 3   229
-12 3   229
-10 2   229
-11 3   230
-11 3   231
-11 3   230
-15 14  227
34  104 210
138 95  191
243 18  88
323 -15 74
280 -8  -2
263 -2  37
212 10  163
16  39  233
28  114 195
29  161 170
33  124 211
5   49  244
7   22  224
-10 3   229
-11 2   230
-12 2   230
-11 3   231
-12 4   228


Infrared receiver gives only zeroes for results

I GUESS that it might be because of the following:

You declare results (it will be initialised to zeros)
In loop, you print the results.decodeType (which will be zero)
You then print results.value, which is still zero.
You then call irrecv.decode() which fails for some reason.
The code loops and starts printing lots of zeros.

You need to find out IF irrecv.decode() is failing and if so why. So add an else clause to catch it in the act.


Sure. Using new or malloc to set things up initially is really no different to static allocations. There is nothing inherently bad with using malloc or new, only in using it repeatedly with free or delete.

Allocating a block of heap memory and keeping it allocated for the rest of eternity does not cause heap fragmentation. It's only repeated allocation and deallocation of variable sizes (such as String causes) that start to create problems. Allocating at the start of your program and leaving it allocated, as long as you don't allocate too much, of course, is not a problem.


How to keep the regulator cool while battery powering the arduino and accessories?

1W is near the limit of what a small LDO can handle. It will get considerably hot.

I would use 4 batteries instead of 5, and a 3.3V Arduino clone instead of the UNO, and power the LEDs directly from the batteries. You could also use your original UNO, feeding it with 6V on a 5V pin through a simple diode, which would drop it to something like 5.4..5.3V.


Nothing is 100% secure. For example, EEPROM and flash can be read using techniques like Scanning Probe Microscopy & Scanning Electron Microscope, even if the security bit is set. IMO, the goal to safely securing your data is to make it extremely hard. You should take a look at the ATAES132a from MicroChip.

  The first device in the AES family, the ATAES132A, is a high-speed, high-security, 32K Serial EEPROM that enables authentication and confidential nonvolatile data storage

It also boast a tamper resistant hardware

  The ATAES132A device contains physical security features to prevent an attacker from determining the
  internal secrets. ATAES132A includes tamper detectors for voltage, temperature, frequency, and light, as
  well as an active metal shield over the circuitry, internal memory encryption, and other various features.
  The ATAES132A physical design and cryptographic protocol are designed to prevent or significantly
  complicate most algorithmic, timing, and side-channel attacks.


In the C family of programming languages, the division operator (/),
when used with integer arguments, provides an integer division. You
get the integer quotient, and you can use % to get the remainder.

If you want a floating point division, then at least one of the
arguments should be a floating point number. E.g.:

Serial.print(valor / 700.0 * 255);

(the DEC argument is redundant). The final result is then truncated to
an integer before being passed to Serial.print().

A better option, which is outlined in dhimaspw's answer, is to do the
multiplication before the division. This way you avoid costly floating
point operations. If you do that, however, you should be careful about
overflows: valor*255 can be as big as 1023 × 255
= 260865, which is larger than the maximum value an int can store
(215−1 = 32767). You should then write

Serial.print(valor * 255L / 700);

where the L suffix forces the operation to be carried using long
integers.

The simplest solution, however, is to use the Arduino function map(),
which does essentially the same as above:

Serial.print(map(valor, 0, 700, 0, 255));


Sainsmart Omron 12V optocoupled 2 channel relay problem

Lets troubleshoot this circuit:

The circuit diagram you put in your question shows a wire creating a short across the relay coil. Check this, as this will definitely stop your fan from spinning. However, I assume this is an error in the diagram.
The picture on the website shows a jumper link between VCC and JD-VCC. Make sure this is removed.
Check that the fan works when you power it directly from the 6V battery. The fan may work only at a higher voltage or run off of AC voltage. Also, the battery could be flat - measure its voltage when it is under a small load.
Drive the input circuitry directly off of 5V. That is connect VCC to 5V and then directly connect IN1 to GND. Open circuit the IN1 input to turn it off. Check that this direct driving opens and closes the relay contacts.
Check the 12V supply. Does the voltage drop significantly when the relay pulls in or out? Does it have enough current? "Each [relay] needs 15-20mA Driver Current" Measure it using your DMM in ammeter mode.
Check your wiring is correct. It sounds simple, but you will be surprised by how many times the wiring is the cause of the problem.
Measure the resistance of the relay contacts in both the open and closed states. Arcing or poor manufacturing can be causes for the contacts to not function as intended.


Is there a library for non-SAMD Arduinos to use the DMP on MPU9250

I did have a look at the MPU9250 DMP library provided by Sparkfun and it seems that it is specifically built for their own board which has an M0 chip on the board. However looking at the library, there seems to be no reasons why it would not work with any other board. The main reason why it might not work with something like the 32u4 board would be because the end firmware is too large or the program need too much RAM that what the 32u4 has.

There is a fix provided on the github issues page for using it with a Nano, which might help you get it work with the 32u4 here and there is another library here that you might be able to use or build up on.

However the best way might be to use a M0 chip itself if you really want to use the same IMU since getting the library to work can turn out tricky. Adafruit does sell a M0 with a Bluetooth board here that you might be able to use.


Programming AT24C16 EEPROM with Arduino Nano

In response to the answer from @timemage I updated my code which now allows me to read and write to the EEPROM chip as intended. Here is the code just in case anyone else wants it quickly:
#include <Wire.h>

#define disk1 0x50    //Address of eeprom chip

void setup(void)
{
  Serial.begin(9600);
  Wire.begin();

  unsigned int address0 = 0;

  writeEEPROM(disk1, address0, 1);

  Serial.println(readEEPROM(disk1, address0), DEC);
}

void loop() {}

void writeEEPROM(int deviceaddress, unsigned int eeaddress, byte data )
{

  const uint8_t i2c_base_address = 0x50;
  const uint8_t upper_three_eeprom_adress_bits = (eeaddress >> 8) & 0x7;
  const uint8_t i2c_address = i2c_base_address | upper_three_eeprom_adress_bits;
  Wire.beginTransmission(i2c_address);
  Wire.write(eeaddress & 0xFF); // address LSB

  Wire.write(data);
  Wire.endTransmission();

  delay(5);
}

byte readEEPROM(int deviceaddress, unsigned int eeaddress )
{
  byte rdata = 0xFF;

  const uint8_t i2c_base_address = 0x50;
  const uint8_t upper_three_eeprom_adress_bits = (eeaddress >> 8) & 0x7;
  const uint8_t i2c_address = i2c_base_address | upper_three_eeprom_adress_bits;
  Wire.beginTransmission(i2c_address);
  Wire.write(eeaddress & 0xFF); // address LSB

  Wire.endTransmission();

  Wire.requestFrom(deviceaddress, 1);

  if (Wire.available()) rdata = Wire.read();

  return rdata;
}


Your question is kind of trivial, but from what I understood you're typing the IP address (that the Arduino displays on the serial monitor)  into your browser.

First, make sure you connect your Ethernet shield to your router using an ethernet cable. (Now it's connected locally...)

Second, even if you type in your Arduino's IP address into the browser, the browser will return nothing because the Arduino simply has nothing to display, and hasn't been programmed to accept requests.

To actually have the Arduino display something you can try the Webserver example sketch or you can follow this great Tutorial that I found very useful for beginners.

BTW ports are only used to expose your Arduino to the Internet, in other words if you don't portforward to your Arduino, your Arduino won't be able to get requests from outside your local network (Wi-Fi,Ethernet).


On Linux "Permission Denied" generally means one of two things:

You're not in the dialout group (or you haven't logged out and logged in since), or
Something else is using the serial port.

For 1:

sudo usermod -a -G dialout ashley
<log out or reboot>

For 2:

The most common culprit is ModemManager. The simplest cure is to uninstall it:

sudo apt-get remove modemmanager


The ADC is ground-referenced, and there's no way to change that. The question is if that's necessary. The ADC has a 10-bit resolution, that's good for 1024 different levels between 0 and 5 V. If you convert the 4-20mA with a 250 Ω resistor to a 1-5 V range you still can discriminate between more than 800 different values.

If that's not enough you can use a differential amplifier to subtract 1 V:

By choosing R3 = 1.25 R1 you convert the 0-4 V range to a 0-5 V range.


Using MQTT to send time stamp - to Arduino

You forgot to set the terminating zero of the c-ctring incoming_msg.

add incoming_msg[length] = 0;


I'm looking for a real small but decent Arduino, that can fit in a watch but power a servo and a gyroscope

Look at the ATtiny85 MCU. It's a small 8pin device, and pretty easy to get up and running using Arduino code. You could also use the ATtiny84 which has more pins and still very small.

Start here: https://code.google.com/p/arduino-tiny/

Also, there are plenty of tutorials on setting up and programming them.

Regarding a custom board, your least expensive route would be to design your own. Otherwise you would need to outsource the design.


How to use bitset/read on 16bit numbers (Arduino)

The main problem that you're having is that binary literals don't exist in C; the Arduino libraries get around this by having every single binary value from 1'b0 to 8'b1111_1111 defined as a macro in cores/arduino/binary.h. The obvious workaround is to use octal, decimal, or hexadecimal literals instead.

unsigned short theGrid[] = {
00,
0,
0x0,
 ...
};

Bitwise operations work as normal.

theGrid[pixelY] |= _BV(15 - pixelX);


Possibility to program the ATmega32u4 on the Arduino Yun using a configuration file

You can't. You'll have to change your macro into a variable and change that variable when suitable data is received through the serial port.

You may also have to trigger a reconfiguration of whatever software is doing the sampling, or reconfigure the hardware, depending on what it is you are sampling.


Cannot upload sketch to Atmega328p TQFP soldered on PCB

It looks like the capacitors on your crystal are considerably bigger than they should be.

You are switching the clock to the external crystal, and because you have such massive capacitors on it it's failing to oscillate.  Without that oscillation the chip can't run, and so it can't respond to the programming.

The crystal capacitors should be roughly 2x the "load capacitance" of the crystal you are using.

  CX1 = CX2 = 2(CL - CSTRAY)


Using a Micro SD card for data logging, bad idea? Reliable?

We've been maintaining a network of loggers (60+ currently deployed) using SD card connected directly to the SPI pins (see: http://www.mdpi.com/1424-8220/18/2/530 for details) and our experience is that the SD cards are really reliable provided you don't have a brown-out when they are writing, even when we abuse them with hot surface deployments in the tropical sun. And we buy them used, (since the older, smaller Nokia & Sandisk cards have lower sleep currents) but test them well with H2testw.
 However there is one problem that develops over time: the actual SD adapters are not made that well, and tend to have solder flux residue left on the little pads used to hold the contact springs, and these will corrode over time if moisture gets in. I give everything a sonic bath in 90% isopropyl until the parts are squeaky clean, and then always put 2x10gram desiccant packs into the logger housings (with color indicator beads). If you are careful about the cleaning, the contacts last for years, but if you forget, and moisture gets into the housing, then the SD card contact spring solder points are often the first things to corrode.


You'll need to store whether the button has been pressed.

bool buttonActivated = false;

...

void loop(){

  buttonState = digitalRead(buttonPin); //Read push button logic.
  if (buttonState == 1 ) {
    buttonActivated = true;
  }

  if( buttonActivated ) {
    printAccel(); //print sensor data
  }

}

to deactivate, use:

buttonActivated = false;


Arduino IDE Based Data Logger - Stops Running

This use of String is dangerous.  You are growing and shrinking the String in a loop and hoping the memory manager prevents any holes from forming:

void clockResetcheck() {

  char clkset[] = "CLKSET.TXT";
  if  (myFile.open(clkset, O_READ)) {

    uint16_t newYr;
    uint8_t  newDay;
    uint8_t  newMo;
    uint8_t  newHr;
    uint8_t  newMin;
    uint8_t  newSec;
    char data;
    String temp;
    int place = 0;

    while ((data = myFile.read()) > 0) {

    if (data == '/' || data == ':' || data == ',') {
      if (place == 0) {
        newDay = temp.toInt();
        temp = "";
      }
      if (place == 1) {
      newMo = temp.toInt();
      temp = "";
      }
      if (place == 2) {
        newYr = temp.toInt();
        temp = "";
      }
      if (place == 3) {
        newHr = temp.toInt();
        temp = "";
      }
      if (place == 4) {
        newMin = temp.toInt();
        temp = "";
      }
      if (place == 5) {
        newSec = temp.toInt();
        temp = "";
      }
      place++;
      if (place == 6) {
        myFile.close();
        break;
      }
    }
    else {
      temp = temp + data;
    }
  }
...

The line

temp = temp + data

is a danger flag.  This sort of concatenation is going to reallocate the buffer used by String to make it fit the result.  The reallocate will leave behind a hole with the previous smaller string.

String has logic to reuse the buffer if possible.  So if you start big, it should not have to reallocate.  Something like:

String temp("12345678");  // allocates the buffer at largest needed size
temp = ""; // clear out

That is a less likely to fragment memory.  You have a few other concatenates in code that are similar danger.

The best advice to long running programs I ever received:

  Stay off the heap.

You are using String inside functions.  That means that buffers are allocated and freed again and again.

A better pattern is to remove all the local String's in functions.  Instead use one global String as a temp buffer.

String g_temp("                        ");
void function1() {
   g_temp = "";
   g_temp += char
}
void functionB() {
   g_temp = "";
   // do stuff with g_temp
}

With this pattern, the allocate happens once when the program starts.  If the size is setup large enough, if will never need to reallocate.  This means your high water mark for memory use is established at the time the program starts.  You don't have to monitor for a week to see if some corner case will run out of memory.


Just use these functions to read/write AS3935 registers, replacing the SPI ones (_devAddr is the device address, usually 0x03) :

// read/write functions for I2C mode
uint8_t AS3935::_i2cRead(uint8_t addr)
{
    // send register number
    Wire.beginTransmission(_devAddr);
    Wire.write(addr);
    Wire.endTransmission(false); // <<<--- THE 'false' here is mandatory!

    // request register data
    Wire.requestFrom(_devAddr, (uint8_t)1);

    // read data
    return Wire.read();
}

void AS3935::_i2cWrite(uint8_t addr, uint8_t data)
{
    Wire.beginTransmission(_devAddr);
    Wire.write(addr);
    Wire.write(data);
    Wire.endTransmission();
}

The "trick" is to use Wire.endTransmission(false) inside the read routine; this avoid to send the stop bit, which is mandatory for AS3935 read operation.


How does one set attributes for SD files?

The Arduino SD library, is based on Github: greiman/SdFat, by William Greiman.

From SD Created File Attributes:

  The basic SD.h library doesn't set the attributes. You notice everything has the same creation date? The library doesn't have any way of knowing what the date is.

However, you need to use a callback function. The following information is from file creation date and time in sd card ?:

  Install the SdFat library - there is an example called Timestamp.ino describing in detail how to do it...

// after your rtc is set up and working you code just needs:

void dateTime(uint16_t* date, uint16_t* time) {
  DateTime now = rtc.now();

  // return date using FAT_DATE macro to format fields
  *date = FAT_DATE(now.year(), now.month(), now.day());

  // return time using FAT_TIME macro to format fields
  *time = FAT_TIME(now.hour(), now.minute(), now.second());
}

//put that outside of any functions, before your 'setup'

//Then inside your 'loop' or 'setup'

void loop(void)
{

  //Other code that does stuff

  //put this next line *Right Before* any file open line:
  SdFile::dateTimeCallback(dateTime);
  dataFile = SD.open(datafilename, FILE_WRITE);

  //other code that does stuff

}

There is another way of achieving this, in a sketch without having to convert to SDFat:

  @donald0000 wants the Date Modified field to show an actual time stamp
  when you look at the files present on the card using Windows Explorer.
  As Billy Ho says, the callback function is the way to do it. You can
  indeed use this function with SD.h  if you don't want to convert to
  SDFat. Here is an example of the function in a sketch. Notice the
  timing of when the date modified time stamp is written, it is when
  file.close() writes the actual data to the card.

#include <SPI.h>
#include <SD.h>
#include <Wire.h>
#include <RTClib.h>

File file;  // test file
const uint8_t SD_CS = 10; // SD chip select
RTC_DS1307 RTC;  // define the Real Time Clock object

 char timestamp[30];

//------------------------------------------------------------------------------
// call back for file timestamps
void dateTime(uint16_t* date, uint16_t* time) {
 DateTime now = RTC.now();
 sprintf(timestamp, "%02d:%02d:%02d %2d/%2d/%2d \n", now.hour(),now.minute(),now.second(),now.month(),now.day(),now.year()-2000);
 Serial.println("yy");
 Serial.println(timestamp);
 // return date using FAT_DATE macro to format fields
 *date = FAT_DATE(now.year(), now.month(), now.day());

 // return time using FAT_TIME macro to format fields
 *time = FAT_TIME(now.hour(), now.minute(), now.second());
}
//------------------------------------------------------------------------------
void setup() {

 Serial.begin(9600);
 Wire.begin();
 if (!RTC.begin()) {
   Serial.println("RTC failed");
   while(1);
 };
 // set date time callback function
 SdFile::dateTimeCallback(dateTime);

  DateTime now = RTC.now();
  sprintf(timestamp, "%02d:%02d:%02d %2d/%2d/%2d \n", now.hour(),now.minute(),now.second(),now.month(),now.day(),now.year()-2000);
  Serial.println("xx");
  Serial.println(timestamp);

 if (!SD.begin(SD_CS)) {
   Serial.println("SD.begin failed");
   while(1);
 }
 file = SD.open("TEST_SD.TXT", FILE_WRITE);
 file.println("Testing 1,2,3...");

 delay(5000);
 file.close();
 Serial.println("Done");
}
//------------------------------------------------------------------------------
void loop() {}


Connecting multiple boards to Arduino Uno r3

Short answer: yes, you can. No pin conflict, but you will need an extra SS pin for the second SPI device. [If you can, use the I2C version of your device.]

Unlike the I2C, the SPI bus uses separate lines for sending and receiving data, and it employs an additonal line (SS, SS1, SS2, ...) for selecting which slave device you are talking to. This adds additonal wires, but also eliminates needing different slave device addressses. So what this means is instead of specifying the address of the slave device, we simply address that slave device by turning on its SS pin. It's a lot more simple.

So, if you have two devices (RFID reader and SD Card Adapter), the conections looks like this:

The thing is, you need to use two Arduino pins for selecting the devices you want to talk to: one pin select the RFID reader; the other, the SD card.

Arduino has a fixed pin assignment for SPI comunications:

Because all devices share the MOSI, MISO, and SCLK lines, all commands sent from the master arrive at each slave device. The SS pin tells the slave whether it should ignore this data or respond to it. Importantly, this means that you must make sure to only have one SS pin LOW.

So you can see now how it's a minimum of four data lines that must be present in any SPI system. The MISO, MOSI, and SCLK signals are shared common with all slave devices. However, the SS chip cannot; it must be separate, because each slave device needs its own unique connection so that it alone can be addressed when the master device wants to communicate with it. So for each additional slave device that you add, you must have an additional line available on the master device for that slave device. So, using the above diagram as an example, if we have added a third slave device, we would have to add another SS3 data line to the master device and then connect to the SS pin of that third slave device.


How to connect two LED strips (APA102/SK9822) to Arduino UNO?

I don't know about SK9822 LED strips, however the other type of led strips can be used with every pin; this is to support multiple LED strips.

Because every LED strip has its own CLK input (wire), it would be inconvenient to share them... I'm not sure if it is possible practically, because the timing is critical and if you have just one 'master' CLK signal than the data signals for all LED strips should be sent in time. Also writing the library would be more difficult, since there is a relation between a (shared) CLK signal and other data lines.


How many LED displays can be hooked to one Arduino board?

The led displays will be pretty far out from each other.

Those are I2C connected displays. I2C is not designed (though there are technologies to allow it) to operate over long distances. It's designed primarily for communication between chips within a circuit board.

  How can i uniquely identify the LCD displays?

Since you can't change the I2C address of the displays you would either need a separate I2C bus for each one or employ some form of I2C multiplexer.

All of this is getting too complicated. The more accepted way of doing this would be to have a small microcontroller directly connected to each display (one display per microcontroller) and then make the microcontrollers communicate with each other (or with a single master) over some suitable communication medium (some wireless system, or a serial bus like RS485 or CAN, for example).

You're then just rubber-stamping the units as many times as you want, and connecting them all together.


The Uno can’t run Lua code. The ESP8266 modules like the Wemos D1 or NodeMCU can, with the right firmware.


Convert comma-delimited Arduino String of hex values to array of bytes

You only convert the String object to a char array. It need to further split the char array into substring, and then convert it to number.
To split the char array, you can use strtok() function in c++ to do the job.
There is no str conversion function that can convert "0xff" into uint8_t directly. However, as @rubemnobre mentioned strtol() can be used to convert a c string to a long (in Arduino, it is 4-byte number) and further cast into a uint8_t and store in a byte array.
String s = "0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff";

// Convert String object to char array
unsigned int str_len = s.length()+1;
char charArray[str_len];
s.toCharArray(charArray, str_len);

uint8_t byteArray[7];
int i=0;

// split charArray at each ',' and convert to uint8_t
char *p = strtok(charArray, ",");
while(p != NULL) {
  byteArray[i++] = strtoul(p, NULL, 16);
  p = strtok(NULL, ",");
}

// Print the byteArray
for (i=0; i<sizeof(byteArray)/sizeof(char); i++) {
  Serial.print(byteArray[i]);
  Serial.println(", ");
}
Serial.println();


Instead of 1 and 0, make display say On or Off

Put the strings to display in an array, and output them instead.

char const * const stateDisplay[] = {"Off", "On"};

 ...

lcd.print(stateDisplay[state]);


The ceramic resonator in yellow is connected to the main MCU, and the crystal in red is connected to the other MCU. USB requires tighter tolerances than is available from a resonator therefore a crystal must be used instead.


This sounds as the ATmega328p processor of the UNO was fried. As the UNO has a second processor (ATmega16U2) which is simply a USB-to-serial converter you only see the presence of this in the list of USB devices but it cannot communicate with the board's main processor anymore.

The plug-in order is not that important with the UNO board only but depending on the components you have attached it may be important. especially if the circuit does not have protection against induction current, p.e. fly-back diodes.


Store the current read value AND the previous value and check if a border has been crossed.

E.g.

if Previous value < 500 AND current value >= 500
   Going from 0 to 1 -> return/send 1
else if Previous value >= 500 AND current value < 500
   Going from 1 to 0 -> return/send 0

However, to make it more complicated, you might have debouncing effects, e.g. what if the value moves for some time around 500 to go to 200... It will still result in possibly many 0 and 1 boundary changes.

You can fix this easily by using two different value: by checking going lower < 490 and going higher > 510 (or any other appropriate value. Or use a debounce mechanism where it should be below or above the 500 value for a minimum (but short) amount of time.


I'm not sure about this, but similar to any other serial communication modules used on the Arduino, you need to setup a software serial pins which act as Tx and Rx between the Arduino and the module, XBee in this case. Look at software serial. this should solve your problem. Then you can use the "Serial" object to debug your communication between the two. I have worked with both a GSM and a Wifi module and the method was the same as I have explained above.


Your basic main problem is that you don't know when the button was pressed.  Your timing algorithm always works from the "last time the value was decremented" - and that could be hours ago.  When you press the button the difference between millis() and time_1 could be massive, and it has to count up one second at a time until time_1 passes millis().

What you really need to do is separate out the button from the action. That makes it easier to manage.  You need to find the times when the button transitions from HIGH to LOW (pressed) and from LOW to HIGH (released). You're almost doing that right now, but not quite.  Then when you find the moment of being pressed you can say "From this moment forth you shall count."

For example you might change the first part of your code to be:

if (Pushed != StatePushed) {
    StatePushed = Pushed; // Remember the current state for the next time round
    if (StatePushed == HIGH) { // Released
        Serial.println("Button1 OFF");
    } else { // Pressed
        Serial.println("Button1 ON");
        time_1 = millis(); // Remember what the time is right now
    }
}

That then is a single atomic operation and you can now at any time examine StatePressed to see if the button is pressed or not, and also at the moment of pressing time_1 is set to the current millis() value, so you now know when the button was pressed.

Now you can add your second part using StatePressed as the trigger:

if (StatePressed == LOW) { // Button pressed
    if(millis() >= time_1 + INTERVAL_MESSAGE1){
        bankValue = bankValue - (Button1Value * CostFactor);
        time_1 +=INTERVAL_MESSAGE1;
        print_time(time_1);
        Serial.print("€");
        Serial.println(bankValue);
    }
}

However your method of comparing the time is not good. It doesn't handle the millis rollover problem.  Instead you should be using something more like:

if (millis() - time_1 >= INTERVAL_MESSAGE1) {
    time_1 = millis();
    ... etc ...
}


Why it's not possible to manipulate the TWSR directly?
  i2c c switch

Because your premise is wrong: it is routinely done to manipulate twsr directly.

As to the use of masks, well, because sometimes you only care about certain bits but not others. So you mask away those that you don't want.

Just that simple.


It was "hiccuping" in order to prevent damage from the short circuit condition. Once the short circuit condition is removed, the PSU restores normal operation.

From the reference:
"The operation of hiccup is as follows. When the current-sense circuit sees an over-current event, the controller shuts off the power supply for a given time and then tries to start up the power supply again. If the over-load condition has been removed, the power supply will start up and operate normally; otherwise, the controller will see another over-current event and shut off the power supply again, repeating the previous cycle."


Need help figuring out the pinout of a seven segmented display

Without an image of the display, I'll have to guess. With 12 pins in total, what you most likely have is: 8 pins for 7 segments and the decimal point, and 4 COMMON anodes or cathodes, a detail you will have to discover yourself. This process requires a power source that can safely light LEDs. A multimeter in diode test mode will do since theres usually about 2 V across the probes and some internal resistance, enough to light up the LEDs in the display, though they wont be very bright. I will try to list the minimum number of steps needed to determine the pinout using this method.

Using a multimeter set to diode test mode, place the red probe on any pin (though its good to start at the edges). Now lazily run (i.e. make contact) the black probe through the remaining pins. If the display is a common anode display, you should see the all the segments of a particular digit (not different digits) light up in sequence.
Else, keep running the black probe through the pins until any segment at all lights up. Hold the black probe on that pin that caused the segment to turn on. Now run the red probe through the other pins. If all the segments of a particular digit light up in sequence, this indicates a common cathode display.
Another possibility is that no segment lights up at all, despite steps 1 & 2. Substitute the red probe, where it is held steady, for the black probe. Run the red probe through the remaining pins. If all the segments of a particular digit light up, then the display is a common cathode display.
On the other hand, if no digit's segments light up sequentially while running the red probe through the pins, but at least one segment of any digit lights up, then hold the red probe steady on its current pin, and run the black probe instead through the other pins. If all the segments of a digit light up in sequence, then you have a common anode display.

Take note of the pin that was held constant, in any of the cases above.

Now that you know what kind of display you have, you now need to discover the pinout for the segments and common anodes/cathodes. Get paper and pen so you can label each pin with its function. Create a table with pin numbers in one column (pin 1 - 12) and the pin functions (which you will find out) in the second column.

This image shows the segment labels. During the testing above, one
probe (PROBE A) was held steady on one pin while the other (PROBE B)
was run through the other pins. This caused all the segments of a
digit to turn on. The pin connected steadily to PROBE A is the COMMON pin for
the digit whose segments lit up. So in your table, Pin xx = COMMON
for Digit yy.
To get the COMMON for other digits, move PROBE A to another pin and
run PROBE B through the other pins until another digit has all its
segments turned on in sequence. The pin connected to PROBE A is the
COMMON for that digit. Include this in your table. Repeat until you
have identified the COMMON for each digit.
Finally to get the segment pins A - G and DP, place PROBE A on any of the COMMONs you have in your table and run PROBE B through the other pins. Each time a segment lights up, the pin connected to PROBE B should be associated with that segment's label in your table. E.g. if segment C lights up when PROBE B is on pin 10, then the table should have something like pin 10 = C. Keep going until you have all the segment pins identified.


communication between two arduinos using ENC28J60?

You can use the EthernetENC library. See the examples of Arduino Ethernet library on how to use Ethernet libraries for Arduino.
EthernetClient object wraps a TCP socket. A normal TCP socket is connected to IP address and port. EthernetServer listens on a port. If server is contacted by a remote client socket, it creates a local socket connected with the remote client socket on a free port and returns a EthernetClient object wrapping the socket. Everything you write or print to a EthernetClient is send to that one remote socket.
If the client board creates a EthernetClient and connects it to IP address and port of the EthernetServer on your 'server' board, then you get there a EthernetClient from server.available() and this two EthernetClient objects are connected. What you write/print on one side you read only from the EthernetClient object on the other side.
client socket
   if (client.connect(serverIP, PORT)) {
     client.print("request\n");
     String response = client.readStringUntil('\n');
     Serial.println(response);
     client.stop();
   }

server side
   EthernetClient client = server.available();
   if (client && client.connected()) {
     String request = client.readStringUntil('\n');
     Serial.println(request);
     client.print("response\n");
     client.stop();
   }


loading libs from /Users/erinshankland/Documents/Arduino/libraries: reading dir
  /Users/erinshankland/Documents/Arduino/libraries: open
  /Users/erinshankland/Documents/Arduino/libraries: operation not permitted

This is not an Arduino problem but an OS problem.

Either your /Users/erinshankland/Documents/Arduino/libraries is not accessible by your user (check the permissions) or it's not a directory.

You can try, from a terminal:

sudo chown -R erinshankland /Users/erinshankland/Documents/Arduino/libraries
chmod -R 755 /Users/erinshankland/Documents/Arduino/libraries

which will reset ownership and file permissions on the directory and everything underneath it.

If not, then delete your libraries folder (which may in fact be a file, not a folder) and recreate it and repopulate it with your desired libraries.


Multiple peripherals using SPI with a Mega

What's so special about pin 53

Pin 53 is the slave select pin of the SPI peripheral. As such it has a bearing on how the SPI peripheral operates.
It is intimately tied to the master/slave operation in that when it's an input SPI works in slave mode, and when it's an output it runs in master mode.
So to use SPI in master mode, whether you use pin 53 or not, it must be in OUTPUT for SPI to work at all.
There is nothing much wrong with your methodology, but one thing is missing: the initial state of the chip select pins.
You should always start with all chip select pins disabled (i.e., HIGH) rather than in an unknown (probably low - I'd have to check the datasheet) state - the exception might be pin 53 which SPI might itself set HIGH for you.
So if you add:
digitalWrite(FSYNCA, HIGH);
digitalWrite(FSYNCB, HIGH);

right after setting the pinMode for your pins and still use both pins 53 and 49 then it should work.


You have two problems here:

How to take 24 readings on an Arduino with only 6 analog inputs.
How to get the voltage in the range of 0 to 5 volts.

To take 24 readings you can use an analog multiplexer or two. For example the 74HC4051 (8 channels) or the 74HC4067 (16 channels). With both of those you could handle 24 channels.

To read the voltages you could successively read each cell, relative to ground (eg. the first one should be 2 V, the second should be 4 V, and so on up to 48 V).

Cells 1 and 2 are fine, they are lower than 5 V. Cells 3 to 24 are not. You need to set up a voltage divider to divide down the voltage into the range 0 to 5.

The formula for a voltage divider is:

Vout = Vin * R2/(R1+R2)

Let's make R1 to be 10k ohms, and solve for R2 (given that we want Vout to be 5).

R2 = Vout * R1/(Vin - Vout)
R2 = 5 * 10000 / (Vin - 5)

Plugging that into a spreadsheet we get:

Vin    R
6  50000
8  16667
10 10000
12  7143
14  5556
16  4545
18  3846
20  3333
22  2941
24  2632
26  2381
28  2174
30  2000
32  1852
34  1724
36  1613
38  1515
40  1429
42  1351
44  1282
46  1220
48  1163

These aren't particularly easy resistor values to work with, so we'll use standard values and calculate what the output voltage should be (with the spreadsheet):

Vin   R   volts   Scale
2
4
6   47000 4.9474  1.2128    <--- R2 is 47 k
8   16000 4.9231  1.6250    <--- R4 is 16 k
10  10000 5.0000  2.0000
12   6800 4.8571  2.4706
14   5100 4.7285  2.9608
16   4300 4.8112  3.3256
18   3600 4.7647  3.7778
20   3300 4.9624  4.0303
22   2700 4.6772  4.7037
24   2400 4.6452  5.1667
26   2200 4.6885  5.5455
28   2000 4.6667  6.0000
30   2000 5.0000  6.0000
32   1800 4.8814  6.5556
34   1600 4.6897  7.2500
36   1600 4.9655  7.2500
38   1500 4.9565  7.6667
40   1300 4.6018  8.6923
42   1300 4.8319  8.6923
44   1200 4.7143  9.3333
46   1200 4.9286  9.3333
48   1100 4.7568 10.0909

The "Scale" column will be explained in a moment.

Now we are ready to make up a circuit along these lines:

I haven't shown all the battery cells here - I don't have that much energy! But the principle is the same.

The 2V and 4V inputs we can read directly. From 6V upwards we need to apply the scaling factor from the voltage divider network.

That is shown in the "Scale" column above.

The formula for the voltage on the pin is:

float voltage = ((float) rawADC  + 0.5 ) / 1024.0 * Vref;

So assuming Vref is 5V, and you have a reading of 512, then you apply it like this:

 ( 512  + 0.5 ) / 1024.0 * 5 = 2.502 volts

Now you multiply by the scale factor above, so if this was the 34 V input, the scale factor would be 7.25, and the voltage from the battery would be:

2.502 * 7.25 = 18.14  volts

The stage is now set to work out each voltage:

Use the multiplexer "select" pins to choose one of the battery inputs
Take an analog reading
Scale it by the appropriate amount from the table
Work out what the charge in the cell is (by comparing it to the previous one)

For example, if the first cell read 1.9V and the second cell read 3.85V then you know that the difference is 3.85 - 1.9 which is 1.95 volts.


It sounds either (i) like your motor driver is broken or (ii) your code does not operate the H bridge properly.  Check which digital outputs pins of the Arduino control the H bridge and make sure that they do not short out the H bridge.

If you want to try another H bridge, this one is suitable for your application: https://www.pololu.com/product/2990 .  I have worked with this before and it's very easy to use.


I have read other posts saying that they have done similar using an UART with using an FTDI chip.

You have probably misread something. A brand-new, blank ATmega328 can only be programmed over SPI, or via parallel programming (more pins). There is no "native" UART bootloader.

It's possible to use certain FTDI chips to bit-bang the SPI programming interface. This is probably what the posts you're reading are referring to. As the post suggests, though, this is slower than using a programmer which directly supports the SPI interface, and is only really suitable if you don't have a better programmer available.

If space is a concern, one option to consider may be to provide the ISP port as a set of test points and use pogo pins to access it during manufacturing. You can lay out the test points however you want, possibly at a finer pitch than the 100 mil header you're probably used to.

Depending on your manufacturing process, another approach may be to program the chip before mounting it to the board.


PCA9685 seemingly no PWM output Arduino Uno when attempting to do LED dimming

The LED should be (with its inline current limiting resistor) between VDD and the LED pin, not to ground - and then configure the pin for Open Collector mode.


Infrared sensor has a frequency to activate it?

The 38kHz sensor (such as the Vishay series e.g TSOP1838) are designed for use with IR remotes and IR barrier type applications. They are designed to work with IR emitters that oscillate the IR at 38Khz and additionally modulate that frequency with lower frequency pulses. The sensor (receiver) is designed to have high gain at 38Khz and demodulates the signal. The demodulated output signal pulses can be directly decoded by a microprocessor. The main benefit is reliable functioning even in disturbed ambient light thus protecting against uncontrolled output pulses.


This a very partial answer. I do not know your requirements, whether or
not PWM can do the job, etc... I just wanted to point out that you can
make a pulse exactly 8 µs long with this:

#include <util/delay.h>
#include <util/atomic.h>

// Pulse PD3 (digital 18 on Mega 2560)
// for exactly 8 us (128 clock cycles @ 16 MHz)
static void pulse() {
    ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
        PORTD |= 1 << 3;
        _delay_us(8 - 0.125);
        PORTD &= ~(1 << 3);
    }
}

The _delay_us() function from avr-libc is actually cycle-accurate
inline assembly. The 0.125 µs I subtracted is the time needed by
the actual port writes: both the sbi and cbi instructions take two cycles
(0.125 µs), but that delay should only be counted once.
digitalWrite() should always be avoided in time-critical code.

The 242 µs delay between pulses would be harder to generate without
PWM. A timer interrupt at 4 kHz seems like the simplest option, but
it is not cycle-accurate.

Edit: here is the scope trace, showing a quite accurate timing:


Initialization of function pointer array

You should actively zero-initialize your pointers in the constructor of your class.

The "zero-initialization" of the C++ language only applies in certain cases defined here. In certain configurations, e.g., when the object of the class has an explicit constructor which does not initialize the array, or when the class has no constructor and an object is function-locally created by typing myClass myObject;, the pointers are not initialized to nullptr.

They do get automatically zero-initialized via the C++ standard without you doing anything if an object of this class is declared and defined as a global variable, though. Then you have a "static storage location", and your object is zero-init'ed by zero-init'ing every data member. Your array of function pointers gets then member-wise zero-init'ed to the zero-value of a pointer, i.e., nullptr.

But you should write robust code which is always correct regardless of which kind of method is used to instantiate the object. Thus, the for loop in the constructor as you have it is correct.

See the analogous question I asked here (which I asked because I gave an initially wrong answer and felt responsible).


If you want fine control over the phases, I assume you may also care
about having low phase noise. In this case your best bet is to avoid
toggling the pins in software and go for a hardware signal generation.

With an Arduino Uno or similar board, this can probably achieved by
programming a timer. I would try the following:

Configure Timer 1 in waveform generation mode 12, i.e. CTC
mode with TOP = ICR1. Set the compare output mode of both channels
to toggle on compare match. Set ICR1 so that the timer has half the
period of the signal you want. Now you can independently adjust the
phases of both outputs by writing to OCR1A and OCR1B.

Note that those registers are not double buffered in this mode, so you
have to be careful about when you write them.

The Arduino core library has no support for such timer configuration:
you will have to learn how to program it yourself. If you are not
familiar with the subject matter, I recommend you start by reading
Nick Gammon's tutorial on timers.


Unable to light up all the LEDS connected to Arduino using processing

I'm guessing it is a hardware issue as I discussed in the comments above.

I have just set up a breadboard and copied your code verbatim into the Arduino IDE and Processing (I edited the port index to use). It works as desired. Pressing R, G, or Y will turn on the respective LED and releasing it will turn it off.

I can press these three keys in any combination of none on, one only, any two, or all three, and the LED gives the expected result.

Keyboards were not initially designed to have multiple "main" keys pressed down at any one time, the exceptions to these being the modifier keys (Windows/Command, Option/Alt, Control and possibly some others (I'm thinking the older keyboards here that had "other" keys—Scroll Lock, Print Scr, etc—I'm really unsure).

It appears now, that some hardware and software may have overcome this. As I've said, your project works fine for me. Also, you could try three different keys, it could be a result of how the keys are scanned and you may stumble across three that don't interfere with each other.

As I've suggested in the comments to your question, modify the code to utilise the modifier keys instead, or use the keyboard keys as toggles (ie press once for on, press again to turn it off).


Debouncing a limit switch in Arduino ISR with delays

What you can do (and is anyway far better than waiting in interrupt context), is to have a volatile variable, which you set in the interrupt (say to 1) and in the main loop you check it: once it is set, you execute the delay and then read the value.

Alternatively, if you can change the sensor, just trade the mechanical switch for an optical end run sensor. If your moving object has steady movement, you will not get any bounces from the optical coupler. Then you can just poll it.


Coding and libraries for Maxtronix Ultrasonic sensors

Likely work in pulse mode (library you mentioned) and sure work in RS232 serial mode (spec. in data sheet page 2, top, read data number as text).

How many sensors do you need and how fast update rate? Serial mode is easier if you application need small number of sensor at 'nominal' update rate (Arduino has limited number of hardware serial port, although softserial library may help).

Essentially, in pulse mode, the RX and PW pin is similar to Trig and Echo pin on many widely available sensor (several models number, basically following similar principle). Need care about the high and low relationship as may differ from the default value in library.

Taken from the data sheet of LV-MaxSonar®-EZ0

  R X – If held low, the EZ0™ will stop ranging. Bring high for 20uS or
  more to command a range reading.

  P W – This pin outputs a pulse width representation of range

Specifically you may want to first try the simple (old) ping: Ping Ultrasonic Range Finder

Changes needed:

Your sensor data sheet requires 20 μs trigger pulse while the above is 2 μs;
The library read a high pulse. Your sensor data sheet 'send pulse' which likely imply a HIGH pulse, may not need change;
The library use one pin for both in and out. your is one pin in (in for sensor, out for Arduino) for trigger and one put out for measurement.

Also, another library. Note the author states that many sensor from the factory differs (may need small change in code): Distance Detection
with MaxSonar ultrasonic rangefinder.


I'm not 100% certain without my Due in front of me to test this, but as far as I can see, you are configuring your clock to run at 42MHz with "TC_CMR_TCCLKS_TIMER_CLOCK1" and are getting the timer to trigger when the count is "1" with "TC_SetRC(tc, channel, 1);", which would give you 42MHz, not 4MHz.

Since the clock timer still increments during the TC6_Handler() function, I'm guessing that the interrupt triggers a second time before it has exited the function the first time causing a hang.

Try changing your code to "TC_SetRC(tc, channel, 42000000 / 4000000);" to see if that works.  Your interrupt will still be triggered every 10 ticks of the timer which will only give you 20 ticks of the CPU clock to do your work and exit.  I suspect this may still be too little time to exit before the next interrupt is triggered.  If you still don't get the result you want, try reducing the frequency considerably to see if your timer is actually getting configured correctly.  I don't think you can get exactly 4MHz as the Due timer frequencies are not divisible by 4000000, unless my brain is a little fuzzy this morning and I'm missing something obvious...

If you do need to optimise the code inside your handler so it can run faster, let me know and I'll post some ideas when I can get near my Due and my source code for reference.

You could always check out this link that I used when I needed to understand how to set up a timer for my own projects:
http://2manyprojects.net/timer-interrupts
Should that link go dead before you have a chance to read up, this is the example source from that page I modified for my own purposes:

// These are the clock frequencies available to the timers /2,/8,/32,/128
// 84Mhz/2 = 42.000 MHz
// 84Mhz/8 = 10.500 MHz
// 84Mhz/32 = 2.625 MHz
// 84Mhz/128 = 656.250 KHz
//
// 42Mhz/44.1Khz = 952.38
// 10.5Mhz/44.1Khz = 238.09
// 2.625Hmz/44.1Khz = 59.5
// 656Khz/44.1Khz = 14.88 // 131200 / 656000 = .2 (.2 seconds)

// 84Mhz/44.1Khz = 1904 instructions per tick
const int led_pin = 13;
int state = false;
int interruptCtr = 1;
int S = 0;

void setup()
{
  pinMode(led_pin, OUTPUT);
  /* turn on the timer clock in the power management controller */
  pmc_set_writeprotect(false);       // disable write protection for pmc registers
  pmc_enable_periph_clk(ID_TC7);     // enable peripheral clock TC7

  /* we want wavesel 01 with RC */
  TC_Configure(/* clock */TC2,/* channel */1, TC_CMR_WAVE | TC_CMR_WAVSEL_UP_RC | TC_CMR_TCCLKS_TIMER_CLOCK4);
  TC_SetRC(TC2, 1, 131200);
  TC_Start(TC2, 1);

  // enable timer interrupts on the timer
  TC2->TC_CHANNEL[1].TC_IER=TC_IER_CPCS;   // IER = interrupt enable register
  TC2->TC_CHANNEL[1].TC_IDR=~TC_IER_CPCS;  // IDR = interrupt disable register

  /* Enable the interrupt in the nested vector interrupt controller */
  /* TC4_IRQn where 4 is the timer number * timer channels (3) + the channel number (=(1*3)+1) for timer1 channel1 */
  NVIC_EnableIRQ(TC7_IRQn);
}

void loop()
{
  // do nothing timer interrupts will handle the blinking;
}

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// INTERRUPT HANDLERS
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
void TC7_Handler()
{
  // We need to get the status to clear it and allow the interrupt to fire again
  TC_GetStatus(TC2, 1);
  state = !state;
  digitalWrite(led_pin, state);

  if( interruptCtr++ >= 6 )
    {
     interruptCtr = 1;
     S = !S; // are we flashing S or O
     if( S ) // set time till next interrupt
        TC_SetRC(TC2, 1, 131200); // 131200 / 656000 = .2 seconds
     else
        TC_SetRC(TC2, 1, 656000); // 656000/ 656000 = 1 second
    }
}


When dealing with millis and micros you must always use unsigned long variables; otherwise, values will be overflow/truncate.

When doing time arithmetic, you must always use differences, not additions, because of the nature of unsigned arithmetic.

Your updated sketch is this:

void setup()
{
    Serial.begin(9600);
    while(!Serial);
    Serial.println(); Serial.println("Test");
}

#define STEPS 3
unsigned long lightCmd[STEPS] = {4000, 60000, 90000};
int stepe = 0;
unsigned long stepTime = 0;

void loop()
{
    if(millis() - stepTime >= lightCmd[stepe]) {
        Serial.print(stepe);
        Serial.print(".- ");
        stepe = (stepe+1)%STEPS; //I'm bad at naming variables, sorry
        stepTime = millis();
        Serial.print(stepTime);
        Serial.println(" changing"); // debugging
    }
}


problem with reading PS3 controller buttons

The while(!PS3.getButtonClick(CROSS)) is only checked once per loop, so your system will complete a move to POS1, wait 200ms, complete a move to POS2, and wait another 200ms before it can check the controller for another button press.

runSpeedToPosition() is "blocking", which means NOTHING else can happen while it is doing it's task.

Instead, you probably want to avoid blocking functions and set up a finite state machine and use the run() function of AccelStepper, which you should call as often as you can and it will move the stepper one step toward the target position, if it's not yet at the target position.

The following rewrite is not tested, but the general structure should show you how you can change the way the program is written. You should think of the loop() function running and completing a million times a second, and each time through, you check the state (that is, on what step is the system currently on) and act accordingly. Change to a new state when appropriate.

In the example, there are 5 states, corresponding to all possible combinations of what your program could be doing:

STOPPED: the initial state, the stepper has no target
RUNTO1: the stepper is moving toward POS1, but hasn't reached it yet
WAIT1: the stepper has reached POS1 and is now waiting for a specified delay before moving to the next state. This state uses the process shown in the BlinkWithoutDelay standard Arduino example sketch for delaying without blocking.
RUNTO2: the stepper is moving toward POS2, but hasn't reached it yet
WAIT2: the stepper has reached POS2 and is now waiting for the next state

You can also see the situations where a state is changed:

When START is pressed, set a new target position and enter the
RUNTO1 state
When CROSS is pressed, stop all stepper action and enter the STOPPED state
When in RUNTO1 or RUNTO2, and the distanceToGo() is zero, enter to the corresponding WAITn state
When in the WAITn state and the specified time has elapsed, enter the corresponding next RUNTOn state.

Example:

#define POS1 80
#define POS2 0

const uint16_t DELAY = 200;
enum stepperstates {STOPPED, RUNTO1, WAIT1, RUNTO2, WAIT2};

[...]

void loop() {
  static uint16_t last_millis;
  static stepperstates xStepState;
  if (PS3.getButtonClick(START)){
    xStepState = RUNTO1;
    StepperControl.moveTo(POS1); // go to POS1
    Serial.print("\n Starting Movement between POS1 and POS2");
  }
  if (PS3.getButtonClick(CROSS)) {
    xStepState = STOPPED;
  }

  StepperControl.run();

  switch (xStepState) {
    case STOPPED:
      StepperControl.stop();
      break;
    case RUNTO1:
      if (StepperControl.distanceToGo()==0) {
        xStepState = WAIT1;
        last_millis = millis();
      }
      break;
    case WAIT1:
      if (millis() - last_millis >= DELAY) {
        xStepState = RUNTO2;
        StepperControl.moveTo(POS2);
      }
      break;
    case RUNTO2:
      if (StepperControl.distanceToGo()==0) {
        xStepState = WAIT2;
        last_millis = millis();
      }
      break;
    case WAIT2:
      if (millis() - last_millis >= DELAY) {
        xStepState = RUNTO1;
        StepperControl.moveTo(POS1);
      }
      break;
  }
}


An arduino wifi repeater would in theory be very slow. Since you need to record the bit stream to the internal memory, then switch the spi to the transmitter, and send the bit stream, im unsure about what would happen if you miss a few bits in the process.

Arduino Wifi Shield - the price of a wifi shield 85 usd

Wifi repeater ebay the price of a wifi repeater 22 usd.

This makes me question why one would go through the troubble of making a wifi repeater of an arduino.

Even investing in a raspberry pi and a wifi dongle would be less expensive.


How to loop over objects or pass object to function?

There's a couple of fundamental errors in your sketch.  Mainly your construction of your class instances:

SomeClass classA();
SomeClass classB();

Those are taken as functions that return a SomeClass object, not SomeClass constructors.  Instead they should just read:

SomeClass classA;
SomeClass classB;

As for the rest, you are much better off using pointers to the classes - it makes passing them around so much easier.  For instance, your array would look like this:

SomeClass *things[2] = {&classA, &classB};

That is an array of pointers to the objects.  It just stores the addresses that they are at, rather than duplicating the objects into new objects within the array.

Your loop would then run like this:

for (int i=0; i < 2; i++) {
    things[i]->setFoo(100);
}

Note the use of -> instead of . because you are using a pointer to the object.

Similarly your init() function would be like this:

int init(SomeClass *thing) {
    Serial.println("Setting up thing");
    thing->setFoo(100);
}

init(&classA);

However, if you're never going to use the contents of your array with it you could use a reference instead of a pointer:

int init(SomeClass &thing) {
    Serial.println("Setting up thing");
    thing.setFoo(100);
}

init(classA);

That performs the same job as a pointer but leaves you with what looks like a real object rather than a pointer to the object - in fact it's just aliased the object name to a new one at the same address so you can still access it the same using .


Extract arduino collected data periodically

This is a bit crude, but I think you could use an FTDI cable (which is a USB to UART converter) to have a program in your laptop talk to the Arduino using its UART (serial) interface.

To do it, you could plug the USB side of a FTDI serial cable to your laptop. The other end of the cable has a plug with 6 pins, 2 of which are the TX and RX serial signals. You could plug those two signals to pins D0 and D1 (RX & TX) of your Arduino using male-to-male jumpers.

In terms of software, you could code the Arduino sketch to listen on the serial port for a command from your laptop. When the command arrives, it would output the stored data (could be comma separated values with CR+LF as end of line). Your laptop would then listen for the answer and retrieve the data.


How do I use the prototyping area on a SparkFun MicroSD Card shield?

This type of board, "pad per hole", has no pre-made interconnects. If you use thin enough wire sometimes you can push two pieces of wire into the same hole before you solder, say a resistor lead and another wire to connect to the next component. You can also solder an interconnect wire to the protruding leg of a DIP chip. You can make a buss for ground or 5v by assigning a whole row for that purpose, on the top side wire everything that needs to connect to that buss, and on the bottom side solder a straight piece of bare wire to all those wire ends in that row.


Those numbers are the numerical ASCII representation of the characters.

83 = S
101 = e
110 = n
... etc ...

(Find the whole list here: http://www.asciitable.com/)

The reason you are ending up with numbers is because of the type of variable you are receiving the data into - a byte.

A byte stores a number between 0 and 255.  When you add that byte to a String the compiler assumes you want to append a number, since it is a numerical type that you are using.

If you instead tell it to use a char type then the compiler should realise "Ah, this is the numeric representation of a character - I will add the character instead".

You can either change the whole array type:

char message[VW_MAX_MESSAGE_LEN]; // a buffer to store the incoming messages

Or cast the variable to be the right type when you append it:

  sensorname += (char)message[i];

Or better still, don't use the String class since it is really too heavyweight and prone to memory issues for use on a little microcontroller.  Stick to C strings. They take a little more getting used to, but are so much more microcontroller friendly.


Programming problem I need both if else cases to work but only else loop is running

There are so many things wrong with that program I can't begin to sort it out.

Here's some of the most glaringly obvious errors:

if(bluetooth.read() >=0 && bluetooth.read() <=360)

Read a character. Check it's at least 0. Read a second character. Check it's less than 360.  Since characters are between 0 and 255 that will always succeed if there is one character of any form to read (if there is no characters to read you get -1).

else if(bluetooth.read()=='A'||'B'||'C'||'D'||'E'||'F');

Read another character and compare it to 'A'. This if is true if the character read is A. It also succeeds if B, or if C or if D, etc. That's not "if it's equal to C", just "if C". C is a character literal, so it's equivalent to a number. Any number that is not 0 is TRUE, therefore it's equivalent to:

if character is A or TRUE or TRUE or TRUE...

Which of course is just true, so it will always succeed regardless.

char myval= bluetooth.read();
if(myval== 'A')

Read yet another character from bluetooth (I sure hope there are enough there...) then compare it to a list of characters that are the same as you looked at above. You're comparing a new character this time, not the one you compared with the list a few lines beforehand.


I want to know how to record and play radio waves?

This is only a partial answer, but should be enough to get you started.

The parts are:

Build a receiver http://www.somerset.net/arm/fm_only_lowtech.html
Tune it to the right frequency
Use it to detect the codes sent from your remote
Build a transmitter http://makezine.com/projects/super-simple-fm-transmitter/
Tune it to the right frequency
Transmit the codes
Success!

Step 3 is probably best done with a scope - you should find someone who has one, who can operate it, because they can be damaged.


Writing data to a specific address in EEPROM

You are cycling outside the string, thus creating undefined behavior.

Try replacing the second block with this:

char first_eeprom_value1;
if (state1 == LOW) {
  state1 = HIGH;
  char example_string1[4] = "True";
  first_eeprom_value1 = EEPROM.read(5);
  Serial.println(first_eeprom_value1);
  for (int i = 0; i < sizeof(example_string1); i++) {
    EEPROM.update(i + 5, example_string1[i]);
  }
} else {
  state1 = LOW;
  char example_string1[5] = "False";
  first_eeprom_value1 = EEPROM.read(5);
  Serial.println(first_eeprom_value1);
  for (int i = 0; i < sizeof(example_string1); i++) {
    EEPROM.update(i + 5, example_string1[i]);
  }
}

Please note that this is not optimal; I suggest you to use fixed-length strings, and fill the unused spaces with blanks or 0s, so you can read back all the bytes you wrote in a safe way


Are all the pins on Arduino shields available for use?

Short answer: NO.

Each shield adds some feature to the base Arduino Uno board and to do that it's more than probably going to use some of the PINs.
I say more than probably because Arduino do have support for certain protocols which can share the same pins (I2C and OneWire just from the top of my mind), but they are not the most commonly used approaches for shields.

The only reason the shields expose the same set of pins is for stackability, but not every shield is compatible with any other: it depends on the used PINs.

Some shields provide some level of configuration, usually via jumpers, in order to make them usable in more contexts they would usually be.

Documentation regarding the pins used by each shield is generally available along with the shield, but if you buy cheap clones it's no surprise you might have difficulties finding documentation...

The article you were pointing is somewhat creditable because most of what the author says is actually true and real, including the risk of short circuits.

As an example, the test you run with LEDs connected to the Arduino SPI interface (pins from 10 to 13 are used by SPI) could have damaged your board if you didn't use current limiting resistors.


Modifying smart watch or activity armband with further sensors

there are a few DIY, open source armband or watch models like :

https://www.tindie.com/products/ttgo/t-wristband-diy-programmable-smart-bracelet/

which has the sources and tutorials on :

https://github.com/Xinyuan-LilyGO/LilyGO-T-Wristband

it's based on ESP32 and is Arduino ready.the space constraint may not allow for adding a new sensor, but it already comes with a few onboard sensors.
after getting along with ESP32 and the TTGO libraries (which are all provided by the manufacturer LilyGo) that wouldn't be too hard to design a custom band.


Cannot receive and transmit at the same time

I dunno know about the radio interface you are using. But I can see something which will break your code for sure.

The sections, where you read data from the interface on both Arduinos are passed without a delay, interrupt, polling loop or something else.

Which means: your "read" code section is in no way synchronised with the write code section on the other arduino and vice versa. At the point when you call the function "radio.available()" (which probably tests if there's any data available at the receiver fifo) there is possibly one or any number of bytes available, but not necessary the whole transmission from the other arduino. You have to make sure — somehow — that the transmission is finished, before you can call it a day and go on with processing the received data.

To do this you have to

synchronise the beginning and the end of your transmissions on both Arduinos
poll the data on the respective receiver side, until you are satisfied
or run into a timeout you have to apply in case there's a byte or more lost by chance.

I hope this gives you a little bit of orientation where to start.


multiple relays not triggering correctly

As it happens, you are debugging in the dark.  You have half a dozen devices attached to (presumably) some Arduino, driven by some hard-to-read code that might not work properly even if all the devices work ok, and definitely won't work properly if any of them fail or are incorrectly attached.

For example, you can't tell from that code whether your photoSensor works, whether your clap sensor works, or whether your relays work.  Before messing around further trying to test all at once, run some definitive tests on each device individually.  For example, run the following sketch and see if your system is able to turn on all of the relays at the same time.

// Test if relays work ok: First individually for a second each,
// then all together for 2.5 seconds
enum {relay=A0, relay2=A3, relay3=A4, relay4=A5, nRelays=4};
byte rePins[] = { relay, relay2, relay3, relay4};

void setup() {
  for (int r=0; r<nRelays; ++r) {
    pinMode(rePins[r], OUTPUT);    // Set pin to outputs
    digitalWrite(rePins[r], LOW);  // Turn off relay
  }
  Serial.begin(115200);
}

void loop() {
  byte r;
  // Turn relays on individually for a second each, with half-second gaps
  for (r=0; r<nRelays; ++r) {
    delay(500);         // Wait half a second
    Serial.print("Turning on relay #");
    Serial.print(r+1);
    Serial.print(" at ");
    Serial.println(millis());
    digitalWrite(rePins[r], HIGH); // Turn on relay
    delay(1000);           // One on for a second
    digitalWrite(rePins[r], LOW);  // Turn off relay
  }

  // Turn all the relays on
  Serial.print("Turning all relays on at ");
  Serial.println(millis());
  for (r=0; r<nRelays; ++r)
    digitalWrite(rePins[r], HIGH); // Turn on relay

  delay(2500);          // Wait 2.5 seconds

  // Turn all the relays off
  Serial.print("Turning all relays off at ");
  Serial.println(millis());
  for (r=0; r<nRelays; ++r)
    digitalWrite(rePins[r], LOW); // Turn off relay
}

Next, write a sketch to report results from photosensor and clap sensor readings.  Once you know if your hardware is working, try to get your double-clap logic to work without involving the photosensor, or vice versa.  Also, try to make the double-clap logic work just using a button in place of the clap sensor.

Note, to shorten your code and to get rid of some of the features that make it hard to read, do some of the following changes.  With the code slightly shorter, it may be easier to comprehend and debug.

(a) Instead of introducing program constants as integer variables, introduce them as program constants.  For example, instead of the verbose

int relay = A0;
int relay2 = A3;
int relay3 = A4;
int relay4 = A5;

say something like

enum {relay=A0, relay2=A3, relay3=A4, relay4=A5};

which tells the compiler that relay is a constant with the value A0, etc.

(b) Since you don't use variable LEDbrightness for anything, take it out.  With that gone, change the verbose

photocellReading = analogRead(photocellPin);
photocellReading = 1023 - photocellReading;
LEDbrightness = map(photocellReading, 0, 1023, 0, 255);

if(photocellReading > 500){
    photoSensor = 0;
}
if(photocellReading < 500){
  photoSensor = 1;
}

to

photoSensor = analogRead(photocellPin) > 523;

which will set photoSensor to 0 or 1 much as before.  (It is slightly different: It handles a photocellReading==500 case that your code ignores.)

(c) Change the verbose and badly formatted

  if (doubleClap == 0)
    {
      doubleClap = 1;
    }
    else if (doubleClap == 1)
    {
      doubleClap = 0;
    }

to

 doubleClap = 1 - doubleClap;

(d) Refactor to cut about half the code involving detectionSpan.


Register writing by compound assignment and pointer in Arduino due

Why compound assignment works on write-only registers ?

Probably out of force of habit more than anything.  People are used to having to set bits in registers where the other bits can be read and they want them to stay the same, in which case |= makes sense.
I'd considered that |= might be generating a more efficient instruction, but at least with your REG_PMC_PCER1 |= PMC_PCER1_PID36 example objdump indicates that this is not the case.

Where are those constants (PMC_PCER1_PID36,PMC,etc.) defined ?

Code-wise, they're defined in the ATMEL's (now Microchip's) CMSIS files.  These are header files whose existence is somewhat standardized by ARM for these ARM Cortex processors.  Much of their content isn't however.  E.g., you may see a few things related Cortex M3 that are the same between this ATMEL device in an STM32 counterpart, but GPIO registers may be completely different.
My broadly, they're defined by ATMEL in their datasheets.


Convert string into char array in Arduino?

So after a lot of help and some tweaking, I finally got it to work!

String text = server.arg(0);

char buf[text.length()];
text.toCharArray(buf, text.length());
char *p = buf;
char *str;
char bitmap[960]; //960 is fixed for now, need to count amount of commas + 1
int i = 0;
while ((str = strtok_r(p, ",", &p)) != NULL) {
  bitmap[i] = strtol(str, NULL, 16);
  i++;
}

bitmap now contains all the XBM data from the GET request. I ran into some issues, causing the device to restart, because I accidentally forgot that the length of the bitmap array isn't 114 (that's the amount of horizontal pixels of the display). This caused it to overflow by a lot.

Huge thanks to jose can u c for helping me.


How to connect RFID Module to Arduino UNO

Its just a simple RFID module based on UART working on 5V.  EN stands for enable, to enable the chip. It has to be connected to VCC too. Because its active high signal. GPIOs are general purpose io pins. No need of them if you are just reading from RFID.


How to stop transmission i2c on LCD 16x4 i2c

I need to interupt that communicaton for have a good management of lcd or if know a new library with best features. Thank's for help

This sounds like a classical X-Y problem. You have decided on a solution and asking about some "magic" functionality without understanding the library or how the I2C bus works.
It would be better to try to describe the original issue, investigate, propose and discuss solutions. Basically better understand the original issue.
Back to your question:

Wire.endTransmission()

does not really do what you think. It marks the end of a block to be transmitted (previous Wire.write()) and starts the actual transmission to the slave.
This is what the manual says:

Wire.endTransmission()
Description
Ends a transmission to a slave device that was begun by beginTransmission() and transmits the bytes that were queued by write().


Sending a floating point number from python to arduino

Floating point numbers are (should) be stored in IEEE 754 format.

If you simply write the binary bytes of a floating point number down the serial line, it should be possible to unpack them at the other end.

To do this (Arduino C/C++), make a pointer from your variable, by casting the address of it to char*. Void* would probably work too.

 float my_value = 22.812;
 my_port.write((const char *)&my_value, sizeof(float)/*4*/);

And the unpacking - there's a few ways to do this, but I like:

 float incoming_value;
 unsigned char buffer[4];

 // If we read enough bytes, unpacked it
 if (my_serial.readBytes(buffer, sizeof(float)) == sizeof(float))
     memcpy(&incoming_value, buffer, sizeof(float));
 else
     // I/O error - no data, not enough bytes, etc.
     incoming_value = 0

On the other end (python), bytes are best handled with the struct module.  This will handle the packing and unpacking for you.

import struct
...

try:
    ieee754_data = my_serial.read(4)
    my_float = struct.unpack('f', ieee754_data)
catch:
    # I/O Error, or junk data
    my_float = 0.0

And packing:

 ieee754_data = struct.pack('f', my_float)
 try:
     my_serial.write(ieee754_data)
 catch:
     pass #TODO - I/O Error

One more note - You might consider using doubles instead of floats for extra precision.  Python floats have the precision of a C/C++ double already.


Converting Arduino UNO's analog pins to digital I/O

A0 through A5 already have GPIO capability; treat them as you would any other non-PWM pin.

A6 and A7, found in similar boards that use a SMD package, do not have any GPIO capability whatsoever and can only be used for analog input.


When you are asking a question, here or on a forum, then please tell what you did and what the result was. When you say that it is not working, then we have not enough information and your question might not get answered.

I have tested the first link that you gave to Cryptosuite. It is outdated and needs to be fixed.
I renamed "hmacsha256test.pde" to "hmacsha256test.ino".
The compiler errors and warnings are in the lower part of the Arduino IDE. Scroll up to find the first problem and fix that. Repeat it until it works.

The PROGMEM requires that the 'const' keyword is used. For example in "sha256.cpp":

const uint32_t sha256K[] PROGMEM = {

The 'write' function should return a size_t value.

In sha256.h:

// virtual void write(uint8_t);
virtual size_t write(uint8_t);

In sha256.cpp:

size_t Sha256Class::write(uint8_t data) {
  ++byteCount;
  addUncounted(data);
  return 1;
}

Then it compiles and runs on a Arduino Uno, although there is a warning for low memory because 75% of the sram is used.

The second link is a changed version of the same Cryptosuite. It should be able to use the examples of the Cryptosuite, but it does not.
I can make that work as well.

Using the same example of the Cryptosuite "hmacsha256test.pde" (I renamed it to "hmacsha256test.ino"), create a object 'sha' after including the "sha256.h":

#include "sha256.h"
Sha256 sha;

In the example, replace all "Sha256" function calls with "sha" function calls:

sha.initHmac(hmacKey1,20);
sha.print("Hi There");

Then it works as well.


A simple way to test for short between LEDs is to write a loop that lights one of them at a time, one right after the other, for 50ms or so. It's relatively easy to notice two lighting together (a short) or a missing blink in the sequence (an open - and assuming you can see all the LEDs at once).