EmonCMS Inputs and Feeds

Further info on the wireless weather station and the logging app/site EmonCMS.  EmonCMS is fantastic for logging and displaying your sensor data.  I have setup a server on a Beagleboard XM, as I mentioned in previous post.  It works flawlessly if you treat it right.  What I mean is that messing with inputs and feeds can stop your flow.  After finally figuring out how to do the multiple graph (you have to set up ‘Visualization’ tab first), everything was logging like a champ.  Then I thought I would rename some feeds.  The graphs show what is in the feeds, as far as name is concerned.  My mistake is I didn’t see the change immediately happen after I changed names.  So I thought I had to change the Input name as well.  I did see the graph update with new names and thought it was working great.  It wasn’t.  Woke up next day and saw all the logging for sensors where I changed names were stopped – hadn’t updated in 11 hours.  Turns out I wasn’t waiting for feed timing to update graph, so jumped to conclusion it was Input name as well.  You can change names as long as it is just on Feed setup page.  To get sensors updating again, I had to redo the Input Sensor page (delete changed inputs), and let the inputs update by what the WeMos board was sending.  Then I re-established feed logging.  Then I corrected the bogus feeds in Feed page, and changed names to what I wanted.  All works now with sensor names I chose in Dashboard page.

Another thing to realize too…….when feeds are deleted, they are deleted from MySQL database.  At least I couldn’t find them again.  So, be careful deleting feeds, as you may nuke your logged data up to that point.  I was fine with it, as I just got this setup working for about a week.  Renaming a feed is fine, the data remains and is a continuous log record.

Posted under Sensors

Wireless Weather Station Update

There are tons of weather station how-to sites on the Web.  I am not going to run through the how’s and why’s of setting one up.  I will add some info that has helped me get it where I wanted it.  First a little background…….

I had started this project about a year ago.  In between building and moving into a new house, it got sidelined a few times in favor of more pressing projects.  It was first based on an Arduino Nano, and would use NRF24L01 modules to communicate.  That was all well and good, but realized that having an Arduino connected to PC to receive the data was not what I really wanted in the end.  By that time, I had assembled all the sensors and components onto a wooden board to put out in the shed 35ft from the house.  The anemometer, wind vane, and rain bucket was purchased at Switchdoc Labs, but is the same set that can be purchased from Sparkfun.  The base sensor module was the WeatherPi board from Switchdoc Labs (the older version without grove connectors).  This included a Realtime Clock and BMP280 sensor with an I2C interface.  My other sensors assembled were DHT22 for temp/humidity, and an AS3935 lightning board from PlayingwithFusion.

By this time, I had planned on a new setup.  I had purchased a NodeMCU development board based on ESP8266, which looked to be the best compact, all-in-one solution.  WiFi was built-in.  This board was perfect for testing sensor components and the C++ code in the Arduino IDE.  For the lightning detector board, I found using the EmbeddedAdventures 1016 lightning library the easiest.  The code is agnostic towards how the lightning board is hooked up to microcontroller.  All that is required is naming IRQ pin in the code.  The PlayingWithFusion board is great because you do not need to make any physical changes to use SPI or I2C.  No traces to cut or resistors, caps to add.  I chose I2C due to limited digital pins available with ESP8266.  Depending on how you attach the SI pin of lightning board, communication interface is chosen.  This is how it is connected for I2C:

LIGHTNING    MICROCONTROLLER
SDA             SDA
SCK             SCK
SI              VCC
IRQ             D6
CS              GND
GND             GND
VCC             VCC

All sensors were tested with code individually on Arduino IDE, to make sure they worked.  That was all good.  Then came putting the code together and getting digital pins to play nice together.  The ESP8266 has a lot fewer digital I/O than Atmel 328P boards like UNO, etc.  It has only one analog input.  The pinouts can be confusing with multiple versions of RX/TX and SPI printed on the boards themselves.  To get everything to work together, I assumed only one of each.  I2C comes to the rescue by sharing communication port.  Just have to make sure the addresses of your sensors do not overlap.  Using the Adafruit sketch for scanning attached I2C devices clears that question fast.  next I wanted to test the WiFi capability of NodeMCU from my shed.  I don’t know if it was the fact it got power from USB port or that particular unit had antenna issues, but it had spotty connectivity and would lose signal often.  I decided to get a WeMos board, which still uses ESP8266, but has an UNO footprint and standard power connector.  I figured with larger capacitors, and fact I could feed it 9V, it might have steady power to deliver the data over WiFi.  Long story short….the WeMos has connected and delivered data consistently.

wemos

As with the NodeMCU, you have to name your pins by what they are (like D5, D7, and A0) due to pin mapping.  Everything works as it should when that is done.  Due to the lower number of GPIO on ESP8266, uploading and running firmware can be a little more difficult.  One example is I could not sync during upload with IRQ using D4 or D8.  I ended up using D7 and that was fine.  All kinds of reset occurrences can happen with ESP8266.  Most cases, it can be one line of code referring to a library.  I learned that I would only make one change to code at a time and between each change, upload firmware and test with serial monitor.  In the end, I narrowed down most resets and continuous reboots to use of interrupts.  In the final code for this weather station, there are 3 sensors that use interrupts: Lightning board, anemometer, and rain bucket.  What was happening ended up coming from sending data to server over WiFi and interrupts would blow it up.

The key to getting everything running smoothly was to turn off the interrupts right before connecting and sending data to the emoncms server.  After the send, you perform attachinterrupts again for the IRQs.  Here is how the sequence would go in the code – the data transfer to webserver happens between the detach and re-attach interrupts as shown here:

  detachInterrupt(digitalPinToInterrupt(IRQ_pin));
  //added these
  detachInterrupt(digitalPinToInterrupt(intAnem));
  detachInterrupt(digitalPinToInterrupt(intRain));
  Serial.print("Requesting URL: ");
  Serial.println(url);
  // This will send the request to the server
  client.print(String("GET ") + url + " HTTP/1.1\r\n" +
               "Host: " + host + "\r\n" +
               "Connection: close\r\n\r\n");
  unsigned long timeout = millis();
  while (client.available() == 0) {
    if (millis() - timeout > 5000) {
      Serial.println(">>> Client Timeout !");
      Serial.println("Disconnecting...");
      client.stop();
      return;
    }
  }
  // Read all the lines of the reply from server and print them to Serial
  while (client.available()) {
    String line = client.readStringUntil('\r');
    Serial.print(line);
  }
  Serial.println();
  Serial.println("normal closing connection");
  client.stop();
  attachInterrupt(digitalPinToInterrupt(IRQ_pin), alert, RISING);
  //added these
  attachInterrupt(intAnem, serviceInterruptAnem, RISING);
  attachInterrupt(intRain, serviceInterruptRain, RISING);

I decided to use the OpenEnergyMonitor platform for recording and logging my weather.  This is a great way to display your sensors.  The widgets are already created and the graphs and display can be customized to your satisfaction.  The platform runs on a server of your choice (I chose my Beagleboard-XM running Ubuntu 12.04) and is PHP-based and uses MySQL as storage for data.  Here is an example of the emonCMS custom web view:

Open Energy Custom Interface

Open Energy Custom Interface

 

Posted under Sensors

NodeMCU (ESP8266) upload sketches wirelessly

More on the NodeMCU (V1)…..  This little booger is great!  I have tried all kinds of wireless upload solutions with Arduino (Olimexino with ESP8266, Nano with various wireless devices) and the end result of actually uploading the sketch never succeeded.  It all had to do with the reset aspect which causes the bootloader to accept code and overwrite existing code.  I tried all kinds of elaborate methods: softserial, trigger words that closed reset pin, and a few others I can’t remember now.  I just wanted a way to be able to update firmware/sketches while the device was far away and locked up without having to hookup to a usb cable to do updating.

Enter the NodeMCU version of the ESP8266.  Out of the box it works with the Arduino IDE.  No need to mess with LUA.  Once I got the latest ESP8266 code from Github to replace what was in the IDE, everything worked like a charm.  On my Windows 7 PC, that library went into appdata\local\arduino15\packages\ESP8266.  The version that really worked was 2.3, as the version 2.2 that came with IDE didn’t really work with wireless upload.  The key is the ArduinoOTA library that was fixed and updated.  The key for me getting it to work was with the reset.  In the default code, the reset is called when the OTA function failed.  To get it to really work, you do the reset after the upload and Bingo! it all works.

OTA port selection

OTA port selection

After your first USB sketch upload with the OTA library and code in place, you have to close down Arduino IDE, and then restart IDE for the OTA port to show up.  Not doing this step at first made me think the library was not working.  The image above shows the OTA port under ‘network ports’.  This capability all comes from Arduino Yun wifi procedures, so anyone with that board would be familiar with the network port in the list.

There really isn’t much more to it than that.  The only downside as far as I can tell is the serial monitor falls out of the mix. You cannot use network port with serial monitor because it relies on Yun firmware that asks for SSH password.  You can still use the USB port powering the nodeMCU board if you use another terminal program (like Putty) to see what is coming over serial.

My solution was to hookup an OLED screen to the board and display anything I needed to monitor.  The beauty of using an I2C OLED panel is it only uses 2 wires.  I have a TFT LCD panel which is SPI, and still may use this in the end as it has SD card storage as a bonus.  But for testing, the OLED is easy and just works.

OLED panel on nodeMCU

OLED panel on nodeMCU

Here is the sketch code that grabs a static IP address and allows over-the-air uploading.  It also has the OLED bits for variable monitoring and feedback.

#include <ESP8266WiFi.h>
#include <ESP8266mDNS.h>
#include <WiFiUdp.h>
#include <ArduinoOTA.h>
#include <Wire.h>
#include “SSD1306.h” // alias for `#include “SSD1306Wire.h”`
SSD1306  display(0x3c, D2, D1);

const char* ssid = “your_local_ssid”;
const char* password = “your_wifi_password”;
const char* host = “ESP-OTA”;

#define led_pin BUILTIN_LED
#define blu_pin D4
#define beat 450
IPAddress ip(192, 168, 1, 196); //Node static IP
IPAddress gateway(192, 168, 1, 1);
IPAddress subnet(255, 255, 255, 0);
void setup() {
  Serial.begin(57600);

  // Initialising the UI will init the display too.
  display.init();

  display.flipScreenVertically();
  display.setFont(ArialMT_Plain_10);
  delay(25);

  pinMode(led_pin, OUTPUT);

  Serial.println(“”);
  Serial.println(“Booting”);
  WiFi.mode(WIFI_STA);

  WiFi.begin(ssid, password);
  WiFi.config(ip, gateway, subnet);
  while (WiFi.waitForConnectResult() != WL_CONNECTED) {
    WiFi.begin(ssid, password);
    Serial.println(“Retrying connection…”);
    delay(5);
  }
  ArduinoOTA.setHostname(host);
  ArduinoOTA.onStart([]() { // switch off all the PWMs during upgrade
    analogWrite(led_pin, 0);
  });

  ArduinoOTA.onEnd([]() { // do a fancy thing with our board led at end
    for (int i = 0; i < 80; i++)
    {
      digitalWrite(led_pin, HIGH);
      delay(i * 2);
      digitalWrite(led_pin, LOW);
      delay(i * 2);
    }
    ESP.restart();
  });

  ArduinoOTA.onError([](ota_error_t error) {
    ESP.restart();
  });

  /* setup the OTA server */
  ArduinoOTA.begin();
  Serial.println(“Ready”);
  Serial.print(“IP address: “);
  Serial.println(WiFi.localIP());
  Serial.println(“Now Online!”);
}

void loop() {
  // clear the display
  display.clear();
  float power = WiFi.RSSI();
 String strpower = String(power, 1);
  display.setTextAlignment(TEXT_ALIGN_LEFT);
  display.setFont(ArialMT_Plain_10);
  display.drawString(0, 18, ssid);
  display.setFont(ArialMT_Plain_10);
  display.drawString(0, 32, “POWER: ” + strpower);
  display.display();
  analogWrite(blu_pin, power);
  ArduinoOTA.handle();
  heartbeat();
  delay(30);
}

void heartbeat() {
  digitalWrite(led_pin, HIGH);
  delay(beat);
  digitalWrite(led_pin, LOW);
  delay(beat);
}

Posted under Applications,Sensors

ESP8266 Exception (3)

I swore I had the NodeMCU running on WiFi before, but after uploading new code (not new ESP8266 firmware either) that accesses the wifi library, I got crazy output on serial monitor.  Basically it was an exception and a stack dump (I needed Imodium for my NodeMCU!!) that repeated after any call to the wifi code in library.

Exception (3):
epc1=0x401003e9 epc2=0x00000000 epc3=0x00000000 excvaddr=0x400072f1 depc=0x00000000

I originally had the 2.2 version of ESP8266 source and library and removed it and got latest build at 2.3 for Arduino.  This all done through the ‘Board Manager’ built-in to Arduino IDE.  I also tried adding WiFi.disconnect(true); before calling any wifi code.  The stack dump continued and I got nowhere.  I tried changing boards and tried all ESP8266 varieties to no avail.  Then I did a search on all exceptions and found that a workaround for a (2) exception was to add WiFi.persistent(false).  I’ll be a monkey’s uncle!  That did it.  So, WiFi.disconnect(true) by itself did not solve the problem….persistent(false) did.

Serial.println();
Serial.println();
Serial.println(“——————————–“);
Serial.print(“Connecting to “);
Serial.println(ssid);
Serial.println(“Attempt Login…..”);
WiFi.persistent(false);
WiFi.disconnect(true);
WiFi.begin(ssid, password);

That code above did the trick.

Posted under Uncategorized

Converter Now Works with LuxCore

I had some time to go over the changes that new update to LuxRender has unleashed.  I am very happy and impressed.  I have been avoiding LuxCore API, as previously mentioned, mostly because node implementation was incomplete.  The gaps have been closed and materials all seem to work in nodes.  There are a few things that may be not implemented at this writing, such as ‘Energy Conserving’ on Matte translucent material, etc.  It may be there with Python, but the node GUI does not show it.

Updating my Converter Code is complete and currently testing with various models and scenes.  The speed of LuxCore 2.7 blows away the Classic API modes with my 3D modeling rig.  I had to update my AMD video card to catalyst 15+ or ‘Crimson‘ to get it to even go beyond freezing up in OpenCL.  I can get it to work with LuxCore now, but not all settings complete.  I haven’t nailed down the best settings to get it to complete a render at all times.  Right now I am getting very fast renders with using CPU settings only.  So far, my favorite render settings in LuxCore are Path engine and Metropolis sampler.  Pulled back the consecutive rejections to 425, with a Power light strategy.  I use 6 out of my 8 cores and let ‘er rip.  I am using a fairly large scene for testing with gobs of materials.

london_OBJ_scene_materials

Yes, that is what I am playing with.  If my Converter does not blow up on that, then I can release it into the wild.  That scene has helped in many ways for correcting and updating code.  It caught lighting conversions I overlooked in some of the simpler scenes I was testing with.  This also has a skydome, which I switched to a hemi HDRI light after conversion.

cvtr_gui_update

I am still testing, especially the different LuxCore settings.  In the meantime, I have uploaded the new updated Converter, which is now version 1.6 here.

Posted under Uncategorized

LuxRender Progressing Like Lightning…..

I have been doing all this coding for Blender and LuxRender via my Converter, which takes Blender Internal materials and converts them to LuxRender materials suitable for rendering.  The last LuxRender plugin for Blender I installed had an update feature found in the ‘User Preferences’ section, so I went ahead with updating.  To my surprise, there were some noticeable changes.  It is possible I did not have the latest version previously, as I noticed multiple folders in my ‘blenderaddonsluxrender’ folder as well as the main folder in ‘program files’.  I cleaned up my folders and I have the latest, for sure.  Big change – the output material node changed the slot assignment for light emission.  When I tested my Converter, the light nodes did not connect.  I have fixed this already, but wanted to investigate further what has also changed.  There are a number of things:

  • The image texture node has changed to include a LuxCore specific node.  The old node is called a ‘Classic Image Node’
  • The material selections have been rearranged and updated to apply to ‘classic’ vs. ‘luxcore’.
  • There is a scatter material which currently only works with ‘classic’ API.
  • The bump map factor is no longer under ‘Converter’ or ‘Math’ (I can’t remember now), but in the ‘Texture’ menu
  • There is now a Volume NodeTree (this has moved input assignments to Material Output node)

I am going over my code and testing for rendering in LuxCore.  So far, everything seems to work except for some glass materials.  I will update accordingly.  This is where the latest version of Addon can be retrieved: Convertor for Lux 1.5.5

Posted under 3D Modeling

LuxRender Converter Update and Tweaks

Happy Holidays!  I have had some time testing and updating code for the LuxRender Converter.  As is the case with any programming, when you update something, you invariably break something that worked before.  The only way to solve this is just to keep debugging and testing.  I have had great feedback from the BlenderArtists community, and example files were suggested to test the Add-on tool and I am most grateful.  The only way to get code bullet-proof is trial and error and more testing.  I have added more capabilities in the conversion code – namely:

  • Transparent Image Mapping
  • Displays and screens handled specifically
  • Bump mapping based on object size
  • Fixed Unicode issues printing log file only
  • Adjusted absorption depth for skin materials

Tested the conversion tool with some of the most materials and object filled scenes I have dealt with (just parsing the file took 16 minutes) in a model file.  That one was the real brute force test – here, called Piper’s Alley.   I was able to enhance the code to process that large file without issue.  Searching through the Web, there are a number of models to download to test.  Below is an OBJ scene created by ‘3DRegenerator‘, a Marvel character display essentially.  No preparation was done to the file, except for placing figures in scene.  The Lux Converter was run and the result is shown here.  I added a city model in background for visibility through windows.

marvel_tst

Before uploading updates and tweaks, I wanted to test again a complete scene exported from DAZ3D.  This one had 3 human figures for testing skin conversion as well as other materials.  This was a complete scene and figures were just thrown together in an environment (I believe one that came with DAZ 4.X).  The goal here was to see if the Converter could catch all the materials both on male and female characters with some materials (like hair style) sharing the same base.  Most importantly for test was to see if it could handle transparency maps for hair and eyelashes, etc.  Those materials never import into Blender or Vue properly.  I think the McTeleBlender script(s) do that transparency conversion, but haven’t tried in years.  This Conversion Tool is Luxrender specific and assumes that the materials in Blender Internal before conversion are what is intended.  Here is the test result:

Capturetotal_scene_import_DAZ

The eyelashes and hair converted perfectly (as well as they can be for that type of hair simulation).  I will continue to test OBJ, 3DS, DAE, and other model formats that get imported into Blender for misfires, but I am quite happy with the output at this time.  It is waaaay better than building materials in LuxBlend individually!!

The latest Add-on can be found here:   LuxRender Converter for Blender (version 1.5.4)

 

Posted under 3D Modeling

LuxRender Converter for Blender

I finally had some time over the Thanksgiving holiday to finish up coding my ‘Holy Grail’ for Blender.  I may have mentioned previously that I am a big fan of LuxRender.  Unbiased rendering is the way to go, in my thinking.  But one thing that has been a big time-sucker is prepping the scenes and objects for rendering in LuxRender.  You see, none of the materials from Blender Internal or Cycles are portable over to LuxRender.  I would have these tremendously detailed scenes that come from assets I purchased and were more often-than-not Wavefront OBJ based.  As-is, Blender imports over OBJ files just fine, and they can render in Blender Internal renderer most of the time.  But switch over to LuxRender and you lose the material settings completely.  I have solved that.  It is based on the framework that Silvio Falcinelli created in his Blender Cycles Converter.  If you like Cycles, I highly recommend that Addon.

blender_wireframe

Wireframe view of scene

Here I have a very complicated and detailed scene from a DAZ3D asset I purchased.  It has 144 objects.  Imagine trying to manually apply materials and textures to that!  With my Addon, the Blender Internal materials are converted in about 3 seconds.  Now you can spend more time tweaking materials and getting your render engine settings just right!

COMPARISON

You can see the differences with the original Blender Renders and then the following LuxRender outputs below the first two.

blender_texture    blender_render

Image on left above is a Blender Render Texture View through 3D Viewport.  The unaltered Blender scene imported from an OBJ file seems intact with all textures and materials matching up.  The image on the right above is the same scene, only it is rendered with Blender Internal engine.  There may be some setting I am missing with Blender Internal, but even though the textures are in the slots, they are not rendering.  Interestingly, the bump map images are.  Anyway, that is the render without performing any adjustments – pretty disappointing.  Blender Internal can get good renders.  In fact, if tweaked and adjusted, it can yield good results.  I am just saying that this scene “as-is” does not yield realistic results.  Then I run my Addon to convert to LuxRender, and then little effort is needed to get a realistic render. I stopped the close-up render below at one hour as it did not have a ‘light portal’ setup.  These images were not doctored or post-processed either, just straight out of the Luxrender engine.

lux_onehour_render    lux_2hour_closer_render

Those images directly above are not doctored or tweaked before rendering.  The one on the left was stopped after 2 hours and the one on the right (or below) after one hour.  It is actually exciting to take a scene created from OBJ data that you have never messed with the material settings, and render it out for the first time with LuxRender.  It is like peering into a new world.  This can be a time-saver in your workflow, so you can spend more time on adjusting certain material settings.  Good example would be the candles above.  the translucent depth and absorption color could be tweaked so you get a good wax effect.

INCLUDED FEATURES

addon_buttonThe interface is fairly simple.  You unselect all the objects and click the ‘Convert’ button shown on left.  If you are in Cycles engine, it should kick you back to Blender Render before conversion.

The tool (Addon) will convert standard objects and their materials. On top of that it will also convert the following:

  • Bump Map Textures
  • Light Bulbs and Flames as light emitters
  • Mirrors
  • All glass and image mapped glass
  • Metals
  • Skin (by body parts)

The ability to create the material overrides above are based on the material name.  For instance, if the material has the word ‘metal’ in the material name, the material will be converted to standard default metal in the LuxRender Material Nodes.  In the case of skin, if the material has the word ‘head’ or ‘face’, it will be converted into a rudimentary Glossy Translucent material for taking on the skin image map.  All materials have a glossy component except Area Light materials, which are Matte Translucent.  They are either Glossy Translucent, Glossy, or Metal.  Most things in real life have a reflection component in some form, it depends how much that component is before we see a shine.  I pondered whether I would do Cloth, but if an object has an image map and a bump map, it may be overkill to have it on a cloth material base.

lux_tech_consoleOn the left here, to test how it would convert a lightbulb into light, I import an OBJ file, which was a sci-fi tech console.  I added a plane for the floor and a plane where a light would be above.  I faced the normal towards the object, name the material in ‘Blender Render’ “lightbulb” and then push the ‘convert’ button.  The image is exactly how it rendered, except I gave the light a greenish hue.  I love not having to do tedious manual material and texture application to get a scene ready to render.

 

After a little cleanup of the code, I may get it onto the Blender Addon page.  In the meantime, I have the Beta here Lux Material Converter.  To use in Blender, just place zip file in a known place, and open up ‘User Preferences’.  Then choose ‘Addons’ menu item to add the file.  At bottom, you choose ‘Install from File’ button and find the zip file.  It will add the list of Addons, which you select to activate.  The tool only shows when you have selected the ‘Materials’ icon from the main properties window.  Here is a Demo Video on its use Demo of Lux Converter .  This is an MP4 file, viewable in Quicktime or VLC.

 

 

Posted under 3D Modeling

Notes on the AS3935 Lightning Sensor

I finally got around to testing this sensor (two actually).  The AS3935 is IC sensor created by AustriaMicroSyetems.  There are a few breakout boards available out there with the chip installed.  The first one I got from Tautic on Tindie is no longer available.  The second breakout board I got was from PlayingWithFusion.  I never really got the Tautic board to work, hence my picking up the second.  I don’t know if it was a bad sample, or I cooked it when soldering on the pins.  All the sketches I ran on it, no matter what I did said the ‘noise floor was too high’.  I haven’t thrown it away, so I may have a go at resoldering the pins (in case one of the connections was wonky) and retrying sketches I know work on the Fusion board.  Ultimately, it would be cool to have two of them working and I could triangulate some kind of directional attribute.  Because they are using different capacitors and arrangement, it may not be a good idea.  If anything, two could eliminate false positives.

Now on to the Fusion board.  This board comes with a capacitor value in picoFarads, which you can apply to the sketch from the company’s website.  I tried the sketch that came from the company, and I got lots of local disturbers and no lightning indicators.  The terminology that is used with this board is ‘Disturber’ for a local man-made type of signal in 500kHz range.  The lightning algorithm also uses this frequency range, but filters and automatically identifies lightning over other signals.  It is not foolproof and there are many adjustments you can make through software registers.  If I were to rate this particular board version with AS3935 chip, I would say about 8 out of 10.  The reason I did not choose 9 or 10 is because I have gotten false positives.  Like I said, there are a bunch of adjustments one can make, and it may be that I need to step up a threshold (or two).  Thresholds for this chip are Watchdog, Spike Rejection, and Noise Floor values.

AS3935 with Olimexino

The connection for this particular board is SPI.  The difference between this board connections and the Tautic is for that one, you are supposed to connect SI to GND.  On the Fusion board it is connected to D9 on Arduino 328 type board.  The other connections are standard SPI.  IRQ is on pin D2 for the 328-based Arduino.

I have tried a number of sketches for this chip and the one that works (in my situation) is the one from ThunderAndLightning.  The automatic calibration may be the key.  It starts off the process with values zeroed out and finds the capacitor value closest to 500kHz.  I made a few modifications to work with my particular setup.  Since I had tried other libraries and sketches, I wanted this library to unique, so I changed header name and corresponding entries in the CPP file.

#include <SPI.h>
#include "TL_AS3935.h"
// #define A_MEGA_1280
#define A_PRO_MINI

Also, for the 328 Arduino, you want to insert interrupt as 1.  This line is an example:

AS3935IrqTriggered = 0;
attachInterrupt(1,AS3935Irq,RISING); // 1 for 328

I used the ‘Log’ sketch because I wanted to use Processing to access the chip and record the activity.  This sketch logs the activity as a CSV file.  I also hooked up a blue LED to indicate lightning.  The code for this is also in the script.  Change it to the pin you will use for your LED.

I must admit, I was surprised that about a half hour after I setup the board and ran the sketch, the blue LED flashed.  I looked at the CSV file and it actually recorded 2 strokes with a minutes time.  The interesting thing is, I am finding that it rarely signals a disturber, but is pretty good with indicating lightning.  I am in Florida and this summer there has been much rain and lightning – perfect testing ground for this.  As I mentioned before, I think I may have to tweak here and there – maybe the spike rejection or watchdog threshold.  I have had a few false positives.  Once I saw the blue LED flash and I went outside and there wasn’t a rain cloud in site.  Just small cumulus clouds scattered about.  the clue it was false was that it said 1Km away – so I couldn’t miss that if it was there.

All-in-all I am happy with this little sensor.

 

Posted under Sensors

Hacked by Plug-In, no doubt………..

I have finally got to point where this site is back online.  I have not devoted much time to re-applying WordPress and uploading content.  About 4 months ago, this site was overtaken and infected its way to the DNS servers.  Typing in the link to this site brought you to a Chinese Yacht club site.  Anyway, the domain name issues are corrected and the content has been purged and cleaned.  The last bits will be updated and corrected in a couple of days, as I finalize media links, etc.

Posted under Uncategorized
1 2 3 4