Date   

Re: Noise on Voltage/Current analog read

Howard Dutton
 

On Wed, May 5, 2021 at 09:17 AM, Howard Dutton wrote:
...so it takes the analog sample in the main loop, averages, then drops it in a global variable.  The "(99 + 1) / 100" can be "(999 + 1) / 1000" or "(24 + 1) / 25", etc.  The depth of averaging gives the frequency response vs. noise tradeoff.  This is referred to as a rolling average and has the advantage of not requiring a massive array of values like a normal average does.
You could also bracket the analogRead() and averaging code so it runs at a fixed interval largely independent of the MCU frequency, etc.  Below is for 1 Hz samples in which case you would probably want the depth of averaging to be only 5 or 10 so it's fairly responsive to changes.

static unsigned long lastSampleTime = 0;
if ((long)(millis() - lastSampleTime) > 1000) {
  lastSampleTime = millis();
  // the code
}


Re: Noise on Voltage/Current analog read

Howard Dutton
 

To do this well you'd probably want to change some code from WebAjax:

#if STAT_DC_CURRENT_ANALOG != OFF
  f = toDCAmps(analogRead(STAT_DC_CURRENT_ANALOG));
  strcpy_P(temp1,htmlInnerStatusDCA);     dtostrf(f,6,1,ws1); strcat(ws1,"A"); if (f==invalid) strcpy(ws1,"Invalid"); sprintf(temp,temp1,ws1); client->print(temp);
#endif

...so it takes the analog sample in the main loop, averages, then drops it in a global variable.  The "(99 + 1) / 100" can be "(999 + 1) / 1000" or "(24 + 1) / 25", etc.  The depth of averaging gives the frequency response vs. noise tradeoff.  This is referred to as a rolling average and has the advantage of not requiring a massive array of values like a normal average does.

// global scope
float currentReading = 0.0;

// in the main loop somewhere
static int currentReadingRaw = 0;
currentReadingRaw = analogRead(STAT_DC_CURRENT_ANALOG);
currentReading = (currentReading*99.0 + currentReadingRaw) / 100.0;

........................

// new code for WebAjax.ino
#if STAT_DC_CURRENT_ANALOG != OFF

  f = toDCAmps(round(currentReading));
  strcpy_P(temp1,htmlInnerStatusDCA);     dtostrf(f,6,1,ws1); strcat(ws1,"A"); if (f==invalid) strcpy(ws1,"Invalid"); sprintf(temp,temp1,ws1); client->print(temp);
#endif


USR-ES1 W5500 Lose IP

rad112g@...
 

I installed the USR-ES1 ethernet adapter, it has W5500 chip, works well but i have a little issue with it when conected to any router in DHCP mode (i use "Ethernet.begin(m);" instead of "Ethernet.begin(m, ip, myDns, gateway, subnet);" and i use DHCP binding, but occurs also in static IP mode:
 
After some sporadic time (about 10 - 20 minutes) the OCS disappears from conected LAN devices or re-appears with IP 0.0.0.0, however the OCS is still fully working throught the configured IP address, this happend to me on a ZTE router, the issue is different depending on wich router model is attached to, on a D-Link instead of get an IP (it shows "---  ---- ----") but still fully working, on a Huawei router lease time is not renewed automatically and OCS dissapears after 1 minute, but still fully working at the configured IP (in this last case i didnt used DHCP binding).

Same occurs with the updated arduino lib for W5500, ethernert2, Ethernet3 or Wiznet lib


Noise on Voltage/Current analog read

rad112g@...
 

Hello Howard, im getting very different values for voltage and current reading, im using 2k2 and 220 Ohm for voltage and ACS712 20A (0,1V/A), some instant measurements differs in about 1V/1A from others. Tried to install 1uF electrolitic or 0,1uF ceramic capacitors but didnt get any sustancial change, there are a lot of example codes for average analog read but dont know how to implement them in your OCS.
Could you give some code for average?


Re: Problems after implementing weater functions

Laurent HOUSSAYE
 

Good morning
Thank you Howard for your answers.
I will slow down the I2C bus. Can I go down as low as 10 or 20 Hz ? is there a minimum frequency specified ?


Re: Problems after implementing weater functions

Howard Dutton
 

On Thu, Apr 22, 2021 at 10:43 AM, Howard Dutton wrote:
I2C speed 10000, is in Hz.
Sorry, glitched on that, it's 20000 Hz.


Re: Problems after implementing weater functions

Howard Dutton
 

I2C speed 10000, is in Hz.

Weather stuff updates at 32 second intervals.  Log entries every 30 seconds are from running averages read from sensors every 2 seconds.  Data is pulled from sensors as needed, one is free to break down the sensor readings so it might be several 2 second polls before data becomes valid then updates at several seconds between, that keeps blocking (i.e. code sitting and waiting) times short.


Re: Problems after implementing weater functions

Laurent HOUSSAYE
 

One problem resolved ! The Weather Charts are now correctly displayed once I have cleared the browser (Firefox) cache...
Now it is time to tackle the I2C bus sensors problem !
Thanks a lot Howard for your support.
Laurent


Re: Problems after implementing weater functions

Laurent HOUSSAYE
 

An interesting extract from a forum :

"The insane sounding lengths like 10, 25, and 100m are perfectly possible, and I use the method often (with UART not I2C, but the method stands) when I need to put stuff together quickly. It's not exactly the best way, though.

The key is to know your input voltage threshold. Make sure the voltage drop in the ground lead is well below this, or else a transmitter at a high ground potential will not be able to pull the voltage low enough. Lack of tolerance for ground offsets IMHO is the biggest reason to use RS485 or can transceivers (I2C over CAN is mentioned in a few application notes).

Ideally, all devices will have their own wall wart and battery and no power will be sent over the ground wire between devices.

But, lets take CAT5 for example. CAT5 can't be higher than 52pf/m, or it isn't CAT5.

100m of 52pf cable has a capacitance of 5200pf or 5.2nf.

5.2n times 20kohms (pullup) gives a time constant of about 104 microseconds. That limits speed to about 10kHz or so.

Using 2.2kohm pullups, you could probably get to 100kHz.

I have heard that devices should have a resistor on SDL and SCK, because of the big capacitive load they are driving, of something like 180 or 200 ohms.

But honestly, I2C is not at all the way to go for long distances. CAN transceivers or RS485 used with normal UART is a robust solution with very good fault protection, ESD resistance, speed, distance, etc, at a cost of a dollar a chip or so, ground offsets don't matter nearly as much so you are free to carry power along with data.

The only downside is that a can transceiver can reach 70ma transmitting and 1 or 2ma just listening, so I2C or direct TTL UART might be useful in extreme low power situations, but consider how much time you actually spend sending."

It seems that if the reading frequency is low enough, there is a chance that the I2C communication may work over large distance. We do not need speed for reading weather sensors data, therefore I am confident it will work if we can drastically reduce the communication frequency on this I2C bus. I also may need to power the sensors with dedicated wall warts and not through the 30 m cable.


Re: Problems after implementing weater functions

Laurent HOUSSAYE
 

I forgot to join a picture :


Re: Problems after implementing weater functions

Laurent HOUSSAYE
 

Goodnews !!! I opened OCS web page from another computer in my home and Weather chart is OK !!!! software is Firefox on both computers... I will clear the cache tomorrow morning on the "faulty" computer and see if it helps !
What does "Wire.setClock(20000)" mean ? 20000 Hz ? every 20000 ms ?
What fequency the OCS web page is refreshed ? What frequency the I2C sensors are asked to send their data ?


Re: Problems after implementing weater functions

Howard Dutton
 

Now... did you ever clear the browser cache?

This is specifically designed so the OCS doesn't need to send that big file every time a page is loaded, so a bad copy in the web browser cache can keep it from working.

You can also use the developer tools in the browser (I use Firefox) to see the http transaction and Charts.js file the OCS sends up, if it sends it.


Re: Problems after implementing weater functions

Howard Dutton
 

I2C rates?

See Weather.ino near the bottom...

  // slow down i2c so long distances work, still plenty fast for our little data being moved around
  Wire.setClock(20000);


Re: Problems after implementing weater functions

Howard Dutton
 

On Wed, Apr 21, 2021 at 10:18 AM, Laurent HOUSSAYE wrote:
But if I open it with Notepad, there is nothing written inside...
Oh yes it does have content, I see 225K size is present.  It's all spaces " " and data is positioned by line

OCS is writing the file and SD is working. 

Btw:

Size = exactly 80 bytes per line x 2 lines per minute x 60 minutes x 24 hours = 230400 bytes.
One log file per day.
If the days log file isn't present it is created fully filled but empty (all " ") then recording data starts.
Data is random read/write accessed, not sequential, the position (row/line) in the file depends on the time of day.


Re: Problems after implementing weater functions

Howard Dutton
 

On Wed, Apr 21, 2021 at 09:33 AM, Laurent HOUSSAYE wrote:
The length of the I2C cable is more around 30 m...
That's longer than I'd ever consider using.  Google it.


Re: Problems after implementing weater functions

Laurent HOUSSAYE
 

I have run the following sketch to test the SD card communication (copied from internet) :

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

File myFile;

String buffer;
String filename = "test";

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


  Serial.print("Initializing SD card...");

  if (!SD.begin(4)) {
    Serial.println("initialization failed!");
    return;
  }
  Serial.println("initialization done.");

  myFile = SD.open(filename + ".txt", FILE_WRITE);

  if (myFile) {
    Serial.print("Writing to " + filename + ".txt...");
    myFile.println("testing 1, 2, 3.");
    myFile.close();
    Serial.println("done.");
  } else {
    Serial.println("error opening " + filename + ".txt");
  }
  //Read file byte by byte
  myFile = SD.open(filename + ".txt");
  if (myFile) {
    Serial.println("Read " + filename + ".txt byte by byte:");

    while (myFile.available()) {
      Serial.write(myFile.read());
    }

    myFile.close();
  } else {

    Serial.println("error opening " + filename + ".txt");
  }

  //Read file line by line
  myFile = SD.open(filename + ".txt");
  if (myFile) {
    Serial.println("Read " + filename + ".txt line by line:");

    while (myFile.available()) {
      buffer = myFile.readStringUntil('\n');
      Serial.println(buffer);
    }
    myFile.close();
  } else {
    Serial.println("error opening " + filename + ".txt");
  }

}

void loop() { }

It seems to operate perfectly as this is what I see frome the serial monitor :

The file TEST.TXT has been created on the SD Card and the following has been written in this TEST.TXT file :


Everything looks as functionning correctly.


Re: Problems after implementing weater functions

Laurent HOUSSAYE
 

I have inserted another SD card (8 Gb reformatted) with Chart.js placed in the root directory, but no change : Weather charts are empty.

New : I now have a file written on the SD Card :


But if I open it with Notepad, there is nothing written inside...


Re: Problems after implementing weater functions

Laurent HOUSSAYE
 

The length of the I2C cable is more around 30 m...


Re: Problems after implementing weater functions

Laurent HOUSSAYE
 

I have inserted a 16 Gb SD card. May be it is to much ? Up to now, no file is written on the SD card, which only contains Chart.js.
Also what is the maximum length of cable for the i2c bus ? Can the bus frequency be reduced to accomodate greater length ? I am around 20 m most of it being Cat 6 ethernet cable.


Re: Problems after implementing weater functions

Howard Dutton
 

On Wed, Apr 21, 2021 at 06:50 AM, Laurent HOUSSAYE wrote:
I need to get these charts correct with these very basic sensors connected before I go further, isn't it ? What would you suggest as further action ?
Check the SD card contents to see that the log files are being written.  They are plain text files, you can open them in notepad on a PC.

Read up on the Arduino SD card support, what works and what doesn't.  Might be the kind of SD card.  How it is formatted (some say windows format doesn't work I've found it is fine.)  Etc.

Attempt to run another example Sketch to see the SD card work using the same libraries the OCS uses.

141 - 160 of 536