AS3935 and weewx.sdb

[Steve Sykes]

I am still getting this in the log.  I am running as3935.py v0.5rc1.

Sep 24 21:32:55 raspberrypi weewx[9576]: as3935: strike at 1.0 km
Sep 24 21:32:55 raspberrypi weewx[9576]: as3935: callback failed: Unit system of incoming record (0x10) differs from 'archive' table in 'weewx.sdb' database (0x01)


Checking the database shows that the column and data are in the database.  I see that the distance units are shown in miles and the as3935 sends distance in km.

sqlite3> select avg_distance, lightning_strikes from archive;

3.10685596|2.0
3.10685596|3.0
1.864113576|2.0
0.621371192|1.0
0.621371192|1.0
0.621371192|2.0
0.621371192|1.0
0.621371192|1.0


I am sure the strike at 1 km is just noise but it is helpful as a diagnostic.  Should just ignore the log?

Steve

[Thomas Keffer]

Your database is set up with US units, but you are trying to put  METRIC into it. 

What does your section [StdConvert] look like in weewx.conf? Did you change it?

What the driver sends out does not matter (so long as it is correct!). It is the job of the StdConvert service to convert it into the unit system used by the database.

-tk

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Sykes]

Hi Tom,

I have not modified [StdConvert]. Another interesting thing is that I don't believe that my extensions.py is getting read. I had to modify wview.py to get the database to include the lightning_strikes and avg_distance.


[StdConvert]
   
    # The target_unit affects only the unit system in the database. Once
    # chosen it cannot be changed without converting the entire database.
    # Modification of target_unit after starting weewx will result in
    # corrupt data - the database will contain a mix of US and METRIC data.
    #
    # The value of target_unit does not affect the unit system for
    # reporting - reports can display US, Metric, or any combination of units.
    #
    # In most cases, target_unit should be left as the default: US
    #
    # In particular, those migrating from a standard wview installation
    # should use US since that is what the wview database contains.
   
    # DO NOT MODIFY THIS VALUE UNLESS YOU KNOW WHAT YOU ARE DOING!
    target_unit = US    # Options are 'US', 'METRICWX', or 'METRIC'

##############################################################################

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

[Thomas Keffer]

Just realized that you're using the as3935 service. In your weewx.conf, make sure that it is included before StdConvert. So, your [Engine] section should look something like this (NOT TESTED):

[Engine]

    

    [[Services]]

        # This section specifies the services that should be run. They are

        # grouped by type, and the order of services within each group

        # determines the order in which the services will be run.

        prep_services = weewx.engine.StdTimeSynch

        data_services = user.as3935.AS3935

        process_services = weewx.engine.StdConvert, weewx.engine.StdCalibrate, weewx.engine.StdQC, weewx.wxservices.StdWXCalculate

        archive_services = weewx.engine.StdArchive

        restful_services = weewx.restx.StdStationRegistry, weewx.restx.StdWunderground, weewx.restx.StdPWSweather, weewx.restx.StdCWOP, weewx.restx.StdWOW, weewx.restx.StdAWEKAS

        report_services = weewx.engine.StdPrint, weewx.engine.StdReport

-tk

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.

[mwall]

On Saturday, September 24, 2016 at 10:07:39 PM UTC-4, Steve Sykes wrote:

I am still getting this in the log.  I am running as3935.py v0.5rc1.

Sep 24 21:32:55 raspberrypi weewx[9576]: as3935: strike at 1.0 km
Sep 24 21:32:55 raspberrypi weewx[9576]: as3935: callback failed: Unit system of incoming record (0x10) differs from 'archive' table in 'weewx.sdb' database (0x01)

steve,

what is the value for data_binding in [AS3935]?

it looks like you have configured data_binding to point at the weewx database, which will always cause problems.

the data_binding is *only* for saving to a separate, lightning database.

out-of-the-box, the as3935 automatically saves to the weewx database (assuming you have extended the schema).

this is all explained in the comments at the beginning of as3935.py

m

[mwall]

On Saturday, September 24, 2016 at 10:07:39 PM UTC-4, Steve Sykes wrote:

I am still getting this in the log.  I am running as3935.py v0.5rc1.

steve,

i have release v0.5

no changes to the code, but i updated the comments and the wiki to show how data_binding is used

sorry for the confusion - the old comments still had weewx 2.x syntax

the first step is to verify that lightning data are being saved to the weewx database (run weewxd directly to validate this, and check the contents of your weewx database).  in your case, based on the sql query, it seems to be working just fine.

do not specify data_binding unless you intend to save data to a separate database in addition to saving data to the weewx database.  the lightning database will be a simple table of dateTime and distance, so you can see the time of each strike and how far away it happened.  from that you can plot circles, or if you have weewx running in two locations, you can overlap circles to infer the strike location on a map.

m

[Steve Sykes]

I have moved it as suggested.  When using the piezo lighter to test it I get this. The [Errno 5] errors occur when using the piezo tester much of the time. The placement of the driver line doesn't seem to make a difference.

Sep 25 12:43:19 raspberrypi weewx[16068]: as3935: callback failed: [Errno 5] Input/output error
Sep 25 12:43:19 raspberrypi weewx[16068]: as3935: callback failed: [Errno 5] Input/output error
Sep 25 12:43:20 raspberrypi weewx[16068]: as3935: callback failed: [Errno 5] Input/output error
Sep 25 12:43:20 raspberrypi weewx[16068]: as3935: callback failed: [Errno 5] Input/output error
Sep 25 12:43:21 raspberrypi weewx[16068]: as3935: callback failed: [Errno 5] Input/output error
Sep 25 12:43:21 raspberrypi weewx[16068]: as3935: strike at 8.0 km
Sep 25 12:43:21 raspberrypi weewx[16068]: as3935: callback failed: Unit system of incoming record (0x10) differs from 'archive' table in 'weewx.sdb' database (0x01)
Sep 25 12:43:21 raspberrypi weewx[16068]: as3935: callback failed: [Errno 5] Input/output error
Sep 25 12:43:44 raspberrypi weewx[16068]: as3935: strike at 8.0 km
Sep 25 12:43:44 raspberrypi weewx[16068]: as3935: callback failed: Unit system of incoming record (0x10) differs from 'archive' table in 'weewx.sdb' database (0x01)
Sep 25 12:43:45 raspberrypi weewx[16068]: as3935: strike at 8.0 km
Sep 25 12:43:45 raspberrypi weewx[16068]: as3935: callback failed: Unit system of incoming record (0x10) differs from 'archive' table in 'weewx.sdb' database (0x01)

[Steve Sykes]

matt,

I understand the service a bit better. I tried setting weewx.conf to make the separate database, which worked. I have reset it to save to the weewx database now. I checked the lightning database and saw a couple "strikes", but they didn't show up in the weewx database. I am pretty sure they weren't real strikes anyway. I have increased the noise floor to hopefully eliminate these false hits. I am also comparing it to the Hobby boards detector. So far there isn't much correlation. The purpose for both detectors is so I know when to disconnect my HF antennas. I can't understand why I get the (errno5) when testing with a lighter. Perhaps I need to find a better way to test it. It may just overwhelm the chip, lightning wouldn't emit energy so close.  We haven't had much lightning here this year, I may have to wait until next year to verify correct operation.

I still would like to know why the values in the database and webpage don't agree, for instance the web page reports 1 mile and the database .62 for the same sample. I think weewx is saying 1 mile but means 1 km, even though it is set to US units.


Steve

[mwall]

On Monday, September 26, 2016 at 9:20:09 PM UTC-4, Steve Sykes wrote:

I still would like to know why the values in the database and webpage don't agree, for instance the web page reports 1 mile and the database .62 for the same sample. I think weewx is saying 1 mile but means 1 km, even though it is set to US units.

steve,

in the default installation, there are two fields added to each archive record (or loop packet, if binding=loop).  these are lightning_strikes (the number of strikes in the period) and avg_distance (the average of the distance for each of the strikes).  when you run weewxd directly, you should see these values, and the units of avg_distance will be in the unit system of whatever units your weather station hardware puts out (look at the usUnits field of record/packet).

these two fields will not be saved to the database until/unless you extend your database schema.  once you have extended the schema, you should see values for lightning_strikes and avg_distance in your database.  the units in your database will be in whatever unit system you specified in StdConvert.target_unit.

saving to a separate database has nothing to do with the weewx database specified in wx_binding.  if you set data_binding with a proper lightning database configuration, then you will see a table with three columns: dateTime, usUnits, and distance.  there will be a row for each lightning strike.  the distance in the lightning database is kilometers, since the unit system of the lightning database is weewx.METRIC.  once again, the lightning database has nothing to do with your wx_binding database.

what you see in web pages will depend on what you have written in your templates.

m

[Steve2Q]

Steve and Matthew: I am still working on my detector and am continuing to follow this thread.

One of the problems I have been having is many false positives, so I decided to change the "calibration" parameter. It started as 6, I then changed it to 8. I did these changes within weewx.conf under [AS3935]. When I look at weewx/bin/user/as3935.py I see that the calibration figure is still 6. My question is do I only change the parameters under weewx.conf or do I also (or only) change as3935.py?

Another question is, should I change "indoors" to "outdoors" under as3935.py?

Thanks, Steve

[mwall]

On Wednesday, September 28, 2016 at 2:58:58 PM UTC-4, Steve2Q wrote:

Steve and Matthew: I am still working on my detector and am continuing to follow this thread.

One of the problems I have been having is many false positives, so I decided to change the "calibration" parameter. It started as 6, I then changed it to 8. I did these changes within weewx.conf under [AS3935]. When I look at weewx/bin/user/as3935.py I see that the calibration figure is still 6. My question is do I only change the parameters under weewx.conf or do I also (or only) change as3935.py?

the whole point of having a configuration file is so that you can change parameters without modifying any code.  if you want a calibration of 8, then do this:

[AS3935]
    calibration = 8
 

Another question is, should I change "indoors" to "outdoors" under as3935.py?

the 'indoors' option is boolean, so you want

[AS3935]
    indoors = false

for an outdoor installation.

m

[Steve2Q]

Matthew. .thank you. I am doing the changes under weewx.conf. As far as the indoor v outdoor parameters, I assume that indoor = true would increase the sensitivity (my senor is indoors), but I wonder if this would lead to false positives.

Steve M

[Steve Sykes]

Steve
I have twp sensors working, one with weewx and one with RPi-AS3935-Web. They are both configured the same and in close proximity to each other.  The one running the web code tags "disturbers", as well tagged lightning. However so far I haven't been able to correlate between the two modules. Nor have I been able to confirm that it detected actual lightning. I wonder if weewx is showing lightning which is really "disturbers". My graph always shows many spikes which are not reported. You can see the graphs at http://www.ecsykes.com

There is a tuning procedure using an oscilloscope or frequency country but I haven't done it yet.

Steve

[Steve2Q]

Steve..your inability to correlate readings between two sensors leads me to believe that (unfortunately) they may be unreliable. Maybe the best test would be two pi's running identical software and check the results.

Steve (N2QLQ)

[Steve Sykes]

I agree, although yesterday we really did have lightning and I was home to see it. Both modules did actually detect lightning and weewx generated the alarm email. I even got warnings from the BlitzortungLive app about the same time.

Steve KD2OM