Current reading for Arduino YUN(HELP!)

Official Hardware Classic Yún
1

Hello everyone! I'm doing current reading from the arduino Yun with a Current sensor(ACS712) and I'm stuck with the code to measure the current. Here is an attached file for the circuit connection.
When I typed "D" to the serial monitor, the current reading is suppose to come out. However, it is continuously displaying 0 when the light bulb is on/off.

Here is the code for the measurement of the current:

#include<Bridge.h>
#include<Console.h>

int sensorValue = analogRead(A0);
char incomingByte;
void setup() {
Bridge.begin();
Console.begin();
while (!Console);

Console.println("Type D");
}

void loop() {
if (Console.available() > 0) {
incomingByte = Console.read();
Console.println(incomingByte);
if(incomingByte == 'D') {
Console.println(sensorValue);
}
}

delay(2);

}

HallCurrent_5.png
HallCurrent_5.png977×408 36.5 KB

2

You are not reading the sensor value anywhere.

This line at the top of your code

int sensorValue = analogRead(A0);

should be

int sensorValue;

and you should change loop() to include

void loop() {
  sensorValue = analogRead(A0);
  // etc

...R

3

Thanks for your reply!
I changed the codes but it is still not working.. I don't think my connection is wrong either.
The readings are also the same no matter the power supply is on/off when the light bulb is on/off.
Here is the attached file of the arduino reading and code.

Arduino problem.png
Arduino problem.png1162×724 91.3 KB

4

Please post your code as a .ino file (or even better, just include it in your Post) and post the erorrs as text.

I can't load an image into my text editor.

...R

5

I've attached the file!

#include<Bridge.h>
#include<Console.h>

int sensorValue;
char incomingByte;
void setup() {
Bridge.begin();
Console.begin();
while (!Console);

Console.println("Type D");
}

void loop() {
sensorValue = analogRead(A0);
if (Console.available() > 0) {
incomingByte = Console.read();
Console.println(incomingByte);
if(incomingByte == 'D') {
Console.println(sensorValue);
}
}

delay(2);

}

arduinoproblem.ino (417 Bytes)

6

From your screenshot, your output is changing, varying from 18 to 21. Your code is working.

If those values represent the readings with the lightbulb on and off, and power on and off, then you have a hardware problem. Please post a schematic of your complete circuit, and a clear picture of your actual setup so we can see the actual connection you have made.

7

My connection(hardware) is exactly the same as this attached photo. Power source to the L of the load, the N goes to the current sensor IP+ and IP- back to the power source. I'm using A0 as the analog input for the arduino!

ACS-712-Basic-Hook-Up.png

8

delay(2); is just 2 milliseconds. Maybe a longer delay would help - at least for testing.

It is better to use millis() rather than delay() as illustrated in several things at a time. An Arduino can do a lot in 2 millisecs.

...R

9

lamela:
My connection(hardware) is exactly the same as this attached photo.

Are you absolutely positively sure about that? It is still very much worth posting a picture of your actual setup, as you could easily be overlooking a detail that could make a big difference.

I would say that you either have a wiring problem, or you are using a very small load like an LED that has such a low current that the small changes you are seeing are valid. What is your load's expected current?

Robin2:
delay(2); is just 2 milliseconds. Maybe a longer delay would help - at least for testing.

It is better to use millis() rather than delay() as illustrated in several things at a time. An Arduino can do a lot in 2 millisecs.

...R

Normally I would agree with you, but I respectfully disagree on two counts: while the input is being read every 2 ms, the value is only being printed when a 'D' character is received, so there should be plenty of time for the new reading to stabilize before it is printed.

And using millis() rather than delay() can have lots of benefits in many applications, but this sketch is so simple that I think delay() has its place here. Using the standard blink without delay scheme here would needlessly complicate the sketch, and give no benefit since the code doesn't need to do anything else during the delay.

Now, if the plan is to greatly expand the sketch, and add a lot of other asynchronous processing, then I think getting rid of the delay() statement has some merit.

10

ShapeShifter:
while the input is being read every 2 ms, the value is only being printed when a 'D' character is received, so there should be plenty of time for the new reading to stabilize before it is printed.

Very true. I had missed that.

...R

11

@ lamela,
when posting code, please use markup. See the attached image.

TIA
Jesse

arduino_markup.png

12

Thanks for the replies!
I think I've managed to get it working.. but how do I send the signal wirelessly from the arduino to labview?

13

lamela:
I think I've managed to get it working..

Please let us know what you did to get it working, it may help the next person who comes along with a similar problem. It's your chance to give back to the community.

but how do I send the signal wirelessly from the arduino to labview?

You're almost there by using the Console class to communicate with your sketch. Now, you just need LabView to access the Yun Console. Check this out: Yun to labview TCP/IP wireless - #27 by sonnyyu - Arduino Yún - Arduino Forum

14

Thanks! I didn't know my code was already working :slight_smile:
I'm required to send the AC signal from the arduino to labview wirelessly.. I'm only able to display readings wirelessly from the arduino to labview but not the signal.
If it doesn't work, I was thinking of plotting the value from the arduino to labview by reconstructing the graph.

My project deadline is coming closer.. Really need the help from you guys! Thank you!

15

lamela:
I'm required to send the AC signal from the arduino to labview wirelessly.. I'm only able to display readings wirelessly from the arduino to labview but not the signal.
If it doesn't work, I was thinking of plotting the value from the arduino to labview by reconstructing the graph.

I don't know what you're saying here. Do you need to send the AC waveform to LabView so that it can be plotted? Right now, you're just sending a single sample at a time. You won't be able to send samples fast enough that way to be able to plot the AC current waveform.

You will need to collect a bunch of samples rather quickly, and store them in an array. Then, when the data is requested by LabView, you will need to send the whole group of samples at once. I'm not familiar with LabView (last used it over 20 years ago, and didn't use it much even back then) so I'm not sure how you would format and process the data. I just know that you won't get there sending one sample at a time.

Right now, you are taking a sample once every 2 ms or so (it's actually a longer time between samples because there is overhead of looping around, and overhead of checking for an incoming command. So now, since the timing is becoming more important, we're back to Robin2's suggestion of getting rid of the delay and using millis() to determine your timing: look at the BlinkWithoutDelay example for ideas. That sketch turns the LED on and off, you will want to replace that whole section dealing with ledState and the digitalWrite() with a call to read and store another sample. The advantage to doing it that way is that the loop overhead and incoming data overhead will have less impact in the timing.

With a 2 ms sample time, you will only get about 8 samples in a 60 Hz period, and about about 10 samples in a 50 Hz period. That may be enough to be able to determine the frequency of the signal, and a very rough wave shape, but it will probably not give you enough points to be able to see a nice waveform. You may need to sample faster than that, so you may need to substitute micros() for millis() in the BlinkWithoutDelay example so that you can get better timing.

Rather than look for an incoming command on every loop (sample) I would probably collect and store a series of samples (enough for a few cycles of the waveform, say 50 or 100 milliseconds worth) and then check for a command to send them. I think checking for incoming data on every sample will take too long and it will mess up your sample timing. Only checking at the end of a group of samples would mean there could be 100 milliseconds or so delay before responding to a data request, but I doubt that LabView will notice that delay

Good luck, this is not a trivial project, but it can be done.