-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't get it to work.. #1
Comments
Btw, I'm using this breakout https://www.tindie.com/products/TAUTIC/as3935-lightning-sensor-board/ And I get this error: root@blixten:~/dev/RaspberryPi-AS3935# python lightning.py |
The only potential issue that I see in your wiring is that you have Vdd set to 5V but your SI is at 3.3V. The datasheet seems to suggest that SI needs to be the same as Vdd to enable I2C. I operated the entire device with Vdd at 3.3V from pin 1 and didn't connect 5V anywhere. |
Hi, I tried 3v3 to start with but thougt it might be a amp-issue. Is the code on github the most recent, I found some compiler errors and I thougt you might have updated it? Rickard. |
The code posted is the latest. Are you getting the same error when Vdd and SI are both connected to the 3.3V supply? If not, what error are you getting? |
While I was typing the readme file I realized that newer Pis will need adjustments to the lightning.py file. If you have a newer Pi give that a try. Hopefully that will take care of the problem. |
Hi, Running on a old pi. Yes, changed back to 3v3 and get the same error: #python lightning.py |
I even changed to another breakout board (had 2) |
What output do you get when you run Did you add resistors R2 and R3? I'm not convinced that you need them since the Pi includes 1.8k pull up resistors, but you could test this fairly easily on a breadboard without having to modify your breakout board. Any value resistor between 2.4k and 10k should be safe to use assuming the only devices on the bus are the Pi and the AS3935. |
I only get a hit on 00 if I type i2cdetect. -a 0. No pullups, do you have them? I thought I didn't need them. Btw did you read about the bug in the firmware that made the chip drop the first packet if you used 00? |
My breakout board came with pull up resistors already installed, so I didn't bother to mess with them, but given the setup you shouldn't need them. I have read about the bug, but haven't encountered it. What happens if you write a short python script that reads 0x01 from address 0x00? Something like import smbus
i2cbus = smbus.SMBus(0)
as3935_data = i2cbus.read_i2c_block_data(0x00, 0x01)
print as3935_data |
That works great!! root@blixten:~/dev# python ss.py |
What happens when you expand it to also include a write? import smbus
i2cbus = smbus.SMBus(0)
as3935_data = i2cbus.read_i2c_block_data(0x00, 0x01)
print as3935_data[0x03]
i2cbus.write_byte_data(0x00, 0x03, as3935_data[0x03] | 0x20) // Set the disturber mask
as3935_data = i2cbus.read_i2c_block_data(0x00, 0x00)
print as3935_data[0x03] |
Sometimes it actually works: root@blixten: |
Would you like to have access to the server yourself? I can give you a login. |
Made this script: import smbus
i2cbus = smbus.SMBus(0)
for i in range(0,1):
while True:
try:
as3935_data = i2cbus.read_i2c_block_data(0x00, 0x01)
print "success.."
print as3935_data[0x03]
except:
print "fail.."
continue
break
for i in range(0,1):
while True:
try:
i2cbus.write_byte_data(0x00, 0x03, as3935_data[0x03] | 0x20)
print "success.."
except:
print "fail.."
continue
break
for i in range(0,1):
while True:
try:
as3935_data = i2cbus.read_i2c_block_data(0x00, 0x00)
print as3935_data[0x03]
print "success.."
except:
print "fail.."
continue
break And get this output: root@blixten: |
You might want to power cycle the sensor. That you got back 255 seems kind of weird there unless something is confused or broken. Also, since the error is presenting itself intermittently, try changing the first read operation to read register 0x00, just to see what happens. |
I did a power cycle and now I get 32 back every time, but I still get error. Could it be that issue mentioned or am I having i2c-issues. Perhaps I should try another pi, I have a few of them lying around. root@blixten: |
I've been told there are issues with this particular revision of the silicon while trying to access register 0x00 over I2C, I would recommend utilizing the board in SPI mode. Here's another individual who identified the I2C issues and has contacted AMS : http://fll-freak.com/blog/?p=554 I have a new version of the board in the works which will allow a user selectable I2C address, and hope to have more detail around the 0x00 issue by that time. |
Have you had a chance to play with this anymore? If this is a hardware issue then I'd like to close it, but want to make sure that there isn't something that I could change in order to fix things first. |
I don't know but I assume it's a hardware bug. I'm a bit to novice to make the SPI-implementation myself, so I have to wait until I find some code for that. |
Hi,
This seems extremely promising but I can't get it to work. I don't know if this is an issue with my installation or the code.
This is my pinout, how does this differ from your installation?
VDD -> 5V -> PIN 2
GND -> GROUND -> PIN 6
Pin 13 (I2CDATA) -> MOSI -> GPIO 2 -> PIN 3
Pin 11 (I2CL) -> SCLK -> GPIO 3 -> PIN 5
Pin 9 (SI) -> SI -> 3V3 -> PIN 17
Pin 10 (IRQ) -> IRQ -> GPIO 17 -> PIN 11
Kind Regards, Rickard.
The text was updated successfully, but these errors were encountered: