search

ironsheep / lightning-detector-MQTT2HA-Daemon

Linux script to monitor AS3935 lightning detector and report detections to MQTT
GNU General Public License v3.0
34 stars 7 forks source link

Not sure if --calc_tuning_cap is working right #10

Closed lightmaster closed 4 years ago

lightmaster commented 4 years ago

Checklist:

Release with the issue: v2.2.0

Last working release (if known):

Hardware, Operating System, Python version:

Description of problem: I tried running the new "calculate tuning cap value" and my values were all identical, whereas the readme examples are all different. Not sure if its working on mine.

Python errors shown in the logs (if applicable):

pi@LightningPi [12:42:17 AM] [/opt/ISP-lightning-mqtt-daemon] [master *]                                                                                                    
-> % python3 /opt/ISP-lightning-mqtt-daemon/ISP-lightning-mqtt-daemon.py --calc_tuning_cap                                                                                  
[2020-09-04 00:43:22] * Mode: Calculate Tuning Cap value and exit                                                                                                           
[2020-09-04 00:43:22] - * init mqtt_client_connected=[False]                                                                                                                
[2020-09-04 00:43:22] * Sensor on SPI bus                                                                                                                                   
* Please allow a long time for this function to stop. It should take a little over 3 minutes to test the 16 values                                                          
For tuning 0x0: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0x1: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0x2: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0x3: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0x4: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0x5: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0x6: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0x7: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0x8: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0x9: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0xa: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0xb: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0xc: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0xd: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0xe: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
For tuning 0xf: average frequency of 0.000000 Hz (diff: +31250.0)                                                                                                           
- Your best tuning capacitor value is 0x0: which is off by +31250.0

Additional information:

ironsheep commented 4 years ago

@lightmaster sorry to hear but you reminded me that i can do more.

In your case, the AS3935 appears to not be talking with the RPi!

I'm adding a read/write check that can point this condition out when you startup the script. I'll post that in about 30mins....

More soon

ironsheep commented 4 years ago

I've added a communications check to the script. It will now abort with an error message if the AS3935 comms are not good.

Please get the latest from the repo. then run the script manually once to check things using the command: ./ISP-lightning-mqtt-daemon.py -d -v

this turns on debug and verbose messaging so you can see the progress of the testing. Please, let me know here what you find out!

lightmaster commented 4 years ago

Yup, comms not working. I'm not that familiar with SPI, any easy way to figure out what is keeping it from connecting?

[2020-09-04 17:08:29] - (DBG): - Testing AS3935 Communications...
[2020-09-04 17:08:29] - (DBG): log: Received PUBACK (Mid: 4)
[2020-09-04 17:08:29] - (DBG): - TEST write=5, read-back=0
[2020-09-04 17:08:29] - (DBG): - TEST write=2, read-back=0
[2020-09-04 17:08:29] * AS3925 Comms not working!  Aborting
ironsheep commented 4 years ago

Ok, shouldn't be too hard. Basically you'll want to make sure that all signals have a good solid connection. Take note of MISO and MOSI. You want to make sure that MOSI RPI is connected to MOSI AS3935. Likewise, make sure that MISO RPi is connected to MISO AS3935.

After you've ensured that you have a good solid connection for all then you should get past the comms check.

The tuning routine will not work tho' if you also don't have a good interrupt line connection. (There's no indication that this is part of your problem. I'm just saying this line needs to be checked, too. This line must also be correctly identified in your config.ini too or the tuning still won't work.

In recalling your question about reverting back to SPI from I2C... the pull-ups ("I2C Pull Up resistors") pads only affect signals sent from the RPi which should be strong enough to get past the pull-ups. But we'll keep this in mind if just fixing connections doesn't get you going.

ironsheep commented 4 years ago

@lightmaster any news? my info help?

lightmaster commented 4 years ago

Sorry, work nightshift and just got a chance to test it now.

I have set it up on a breadboard and double checked all connections. I have used a multimeter to verify that there is a solid connection between all the GPIO pins and the pins on the modules. I have also cut the connection between the I2C PU bit and made sure there is no connection between those 2 pads. I've also made sure the I2C EN pads are back the way they originally were originally. Still, test says the SPI comms are not working.

One weird thing I noticed is that the Power LED is still lit when 3v3 pin is disconnected, though not as bright as it is when the 3v3 pin is connected.

ironsheep commented 4 years ago

Sorry to hear... I'd say recheck your I2C <-> SPI jumper changes by measuring with your meter. For SPI:

(meter the following two pins with power on but /CS disconnected from RPi - meter set to DC Volts)

Then reconnect all and recheck connections to RPi (you might have already done this, worth doing again since the problem hasn't been found yet - meter set to open/short testing)

re: power still on - recheck which pins you are using on RPi... it can be easy to be off by one... (yeah, I've done it ;-) I'll see if this happens on mine...

lightmaster commented 4 years ago

@ironsheep I'll check this when I get home tonight. Worst case, still have a week to return to Amazon as defective and get a different one. Found a different one that the manufacturer doesn't say there are issues with I2C.

lightmaster commented 4 years ago

CS is pulled up to 3.19v The SI pad is shorted to GND CS shorted to CE0 INT shorted to GPIO 25 SCK shorted to SCLK MISO shorted to MISO MOSI shorted to MOSI

ironsheep commented 4 years ago

Geez, this is frustrating... sorry to hear.

You say /CS is pulled to 3.19v is that what your 3.3v measures to ground? If they aren't the same then maybe something affecting the ability for /CS to get to be asserted when it needs to? I dunno, nothing obvious. Thanks for checking. I wish we had found something.

If you have the gear then I'd suggest you hook up a logic analyzer to look at the signals ... to see which aren't toggling as they should. I still think something is affecting the proper shape of the signals... (or the chip is just no longer functioning - hope this is not the case.)

I show the waveforms i'm seeing in https://github.com/ironsheep/lightning-detector-MQTT2HA-Daemon/blob/master/THEOPS-SPI.md

FYI- I moved my board back to i2c and it's working there too. Mine is just one short/open to change tho'.

lightmaster commented 4 years ago

Sparkfun admits they don't trust this manufacturer's implementation of I2C, which kills my trust in anything about the board. Already submitted a return with Amazon to return it as defective and got a new one with the same AS3935 chip but made by a different manufacturer. It's also got a more thorough set of pins on it, so I can toggle between I2C and SPI on the breadboard, no semi-permantent changes needed. Should be in by the end of the week.

lightmaster commented 4 years ago

New Board came in today GY-AS3935, SPI still not responding. SI is shorted to IRQ as the Amazon page says it should be. This is different than what you had said about shorting SI to GND.

I switched it over to I2C and ran the -d -v test and it did come back with * Have good comms with AS2925.

lightmaster commented 4 years ago

Back to the problem this issue was opened for. Using I2C, I still get this error when I try to calculate the tuning cap:

pi@LightningPi [02:29:49 PM] [/opt/ISP-lightning-mqtt-daemon] [master *]
-> % python3 ./ISP-lightning-mqtt-daemon.py --calc_tuning_cap
[2020-09-10 14:30:28] * Mode: Calculate Tuning Cap value and exit
[2020-09-10 14:30:28] - * init mqtt_client_connected=[False]
[2020-09-10 14:30:28] * Sensor on I2C bus
[2020-09-10 14:30:28] - - Testing AS3935 Communications...
[2020-09-10 14:30:28] - - TEST write=5, read-back=5
[2020-09-10 14:30:28] - - TEST write=2, read-back=2
* Please allow a long time for this function to stop. It should take a little over 3 minutes to test the 16 values
For tuning 0x0: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0x1: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0x2: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0x3: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0x4: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0x5: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0x6: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0x7: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0x8: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0x9: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0xa: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0xb: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0xc: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0xd: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0xe: average frequency of 0.000000 Hz (diff: +31250.0)
For tuning 0xf: average frequency of 0.000000 Hz (diff: +31250.0)
- Your best tuning capacitor value is 0x0: which is off by +31250.0

As evidenced in this screenshot, it was able to detect a strike, or at least some sort of a signal, but not able to calculate the tuning cap: screenshot

lightmaster commented 4 years ago

Ignore the previous comment, after a reboot, I2C fails read check and will not work either. Opened a separate issue with the error I received.

ironsheep commented 4 years ago

Ok, good to hear of your new device arriving!

Can you send me an Amazon link to the one you purchased? That way I can know which hardware you are using.

I'll look at #13 as something seems definitely wrong there. The version prior to the latest had broken i2c code, I'm assuming you've already updated past that tho'

Also for this 0.00 Hz issue. I've done this to myself, too. If the script can't sense the interrupt line you'll get this list of zeros' during the test.

Please verify which GPIO pin the interrupt line is connected to then double-check your config.ini to make sure the interrupt pin in there is the same. If they are not, then zeros. This is most likely the problem here. If they match then (less likely) it would indicate the interrupt signal is not arriving (electrical/connection issue.)

Let me know what you find out.

lightmaster commented 4 years ago

This is the board I got https://www.amazon.com/gp/product/B087358RNT/

lightmaster commented 4 years ago

After getting the board recognized by the RPi, still nothing as far as tuning. I remembered you saying that nothing over INT would cause the tuning to fail, so I switched from GPIO 17 to GPIO 27 for INT and it started working. Looks like this RPi might not be long for this world. :'(

ironsheep commented 4 years ago

Good to hear, Closing... that it's working, not about the RPi... ;-)

Vollans commented 2 years ago

Hi, for interest, I encountered the same issue. Turns out on the Raspberry Pi 3B what looks like GPIO 7 or 17 (depending where you look) is actually GPIO4. Changed to that, it works.