Page 5 of 5

Re: volts.py output problem

Posted: Sat Mar 03, 2018 9:26 pm
by sm7tix
I have got it working!
In /boot/config.txt i have
dtoverlay=i2c-bcm2708
dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=spi=on

and i get
root@raspberrypi:/home/pi/rover/democode# python volts.py
Battery Voltage: 4.072
4.072
4.072

I hope this help others.
Stefan

Re: volts.py output problem

Posted: Sat Mar 03, 2018 9:51 pm
by gpvillamil
Thats great!

Can you show your lsmod results too?

sm7tix wrote:I have got it working!
In /boot/config.txt i have
dtoverlay=i2c-bcm2708
dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=spi=on

and i get
root@raspberrypi:/home/pi/rover/democode# python volts.py
Battery Voltage: 4.072
4.072
4.072

I hope this help others.
Stefan

Re: volts.py output problem

Posted: Sat Mar 03, 2018 10:03 pm
by sm7tix
My lsmod
(rover)pi@raspberrypi:~ $ lsmod
Module Size Used by
bnep 20480 2
hci_uart 24576 1
bluetooth 368640 21 hci_uart,bnep
ecdh_generic 28672 1 bluetooth
brcmfmac 307200 0
brcmutil 16384 1 brcmfmac
spidev 16384 0
cfg80211 573440 1 brcmfmac
rfkill 28672 4 bluetooth,cfg80211
snd_soc_bcm2835_i2s 16384 0
snd_bcm2835 32768 0
snd_soc_core 188416 1 snd_soc_bcm2835_i2s
snd_compress 20480 1 snd_soc_core
snd_pcm_dmaengine 16384 1 snd_soc_core
snd_pcm 98304 4 snd_pcm_dmaengine,snd_soc_bcm2835_i2s,snd_bcm2835,snd_soc_core
snd_timer 32768 1 snd_pcm
spi_bcm2835 16384 0
snd 69632 5 snd_compress,snd_timer,snd_bcm2835,snd_soc_core,snd_pcm
uio_pdrv_genirq 16384 0
fixed 16384 0
uio 20480 1 uio_pdrv_genirq
i2c_bcm2708 16384 0
i2c_dev 16384 0
fuse 106496 1
ipv6 434176 35

Re: volts.py output problem

Posted: Sat Mar 03, 2018 10:43 pm
by Kevin
Thanks brother! You're my new favorite person today!!! Can't test it right now but this is really really good news. :D :D :D

sm7tix wrote:I have got it working!
In /boot/config.txt i have
dtoverlay=i2c-bcm2708
dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=spi=on

and i get
root@raspberrypi:/home/pi/rover/democode# python volts.py
Battery Voltage: 4.072
4.072
4.072

I hope this help others.
Stefan

Re: volts.py output problem

Posted: Sun Mar 04, 2018 9:12 am
by Nickw58
Yes it now works. Thanks Stefan :D

Re: volts.py output problem

Posted: Sun Mar 04, 2018 5:50 pm
by Kevin
Yep. That's it!!!!!!!!!!!!!!!!!!!!!!!!!! :D :D :D

Use the following command to edit your /boot/config.txt file:

Code: Select all

sudo nano /boot/config.txt


Add the following line. (I added this right above the dtparam=i2c_arm=on line, but I don't think it matters where it goes)

Code: Select all

dtoverlay=i2c-bcm2708


sudo reboot

When it comes back up, volts.py should work. If someone can test some of the other python scripts that would be a second verification, but it looks like we just make huge progress on this.

Thanks everyone. I really appreciate the help!

Re: volts.py output problem

Posted: Mon Mar 05, 2018 10:28 am
by Nickw58
Hi

I ran volts.py, lightsense_ambient, lightsense_surface and rangefinder, all returned values and I was able to see the value change when I manipulated the sensor/s, all except rangefinder this returned a steady value of 87. I put an obstacle at various distances but not change in the value.

Re: volts.py output problem

Posted: Tue Mar 06, 2018 2:56 pm
by gpvillamil
The Python scripts all ran for me, at least initially.

The rangefinder example works correctly, distance values vary depending on where the sensor is pointed (objects at different distances).

After about the 2nd or 3rd time, I started getting the message “error on write”, and sometimes voltage would return as all zeros.

It seems we are not alone: https://www.raspberrypi.org/forums/view ... p?t=178000

I am considering moving to the 4.14 kernel using rpi-update.

Re: volts.py output problem

Posted: Tue Mar 06, 2018 6:19 pm
by TomTheWhittler
I would be careful with rpi-update
I did that before I started to play with the python software and now nothing really works.
I had to do that several times as the Rpi software server kept timing out so things did
not update and install correctly.
First error on running the Python was that it could not find SMbus drivers.
I got that fixed and now it gives a different error of not being able to communicate.
Still hunting this down in the little spare time I have available at the moment.

I am tempted to do a fresh operating system install on a nice 64gb Sansdisk micro card.

Re: volts.py output problem

Posted: Tue Mar 06, 2018 6:30 pm
by Kevin
You may still get a few errors here and there. I have seen those randomly in testing, but it shouldn't be a "lot" of errors. Also note that the Arduino can occasionally hang the bus (seems to have something to do with the bug on the Pi side) - I've only seen this hanging if I have comms from both the Pi and Arduino at the same time and they're stepping on each other (which should be okay technically, but that's when the hang up happens).

I also noticed I get tended to get these errors more often if I was pushing a lot of traffic, so maybe if you slow down the query interval a bit it will help.

Eventually I'd like to get a script running on the Arduino that allows it to realy traffic via SPI. So we would send a SPI transmission from the Pi to the Arduino. We could do this with the existing packet structure, just key the new packet with a different value for this purpose. The second byte can be the I2C target register. The Arduino can then query the PIC via I2C (and this seems to work almost all the time, rarely get I2C errors from Arduino to PIC) - then pack the response into the outgoing SPI buffer. Then the Pi can read via SPI again and get the result. The I2C query is pretty fast so all in all this should still be a fairly quick transaction and may prove to be more reliable in the long run - just a lot more complicated.

gpvillamil wrote:The Python scripts all ran for me, at least initially.

The rangefinder example works correctly, distance values vary depending on where the sensor is pointed (objects at different distances).

After about the 2nd or 3rd time, I started getting the message “error on write”, and sometimes voltage would return as all zeros.

It seems we are not alone: https://www.raspberrypi.org/forums/view ... p?t=178000

I am considering moving to the 4.14 kernel using rpi-update.