I have a UV sensor for a hydroponics setup. It worked fine for awhile, but now I’m getting odd results. It will now all give readings of -1 or astronomically large numbers rather that the 13-15 that it should. I also have a i2c high accuracy barometer that is having similar issues, but I don’t really need it. I’m using the standard code from the seeed sight for a raspberry pi 3b+.
Check space left
Filesystem Size Used Avail Use% Mounted on
/dev/root 58G 4.1G 51G 8% /
devtmpfs 433M 0 433M 0% /dev
tmpfs 438M 0 438M 0% /dev/shm
tmpfs 438M 6.0M 432M 2% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 438M 0 438M 0% /sys/fs/cgroup
/dev/sda1 253M 53M 200M 21% /boot
tmpfs 88M 4.0K 88M 1% /run/user/1000
Check for dependencies
python 2.7.16-1 install ok installed
python-pip 18.1-5+rpt1 install ok installed
git 1:2.20.1-2+deb10u3 install ok installed
libi2c-dev 4.1-1 install ok installed
python-serial 3.4-4 install ok installed
python-rpi.gpio 0.7.0~buster-1 install ok installed
i2c-tools 4.1-1 install ok installed
python-smbus 4.1-1 install ok installed
dpkg-query: no packages found matching arduino
dpkg-query: no packages found matching minicom
scratch 1.4.0.6~dfsg1-6 install ok installed
find: ‘/run/user/1000/gvfs’: Permission denied
wiringPi Not Found (ERR)
find: ‘/proc/2476’: No such file or directory
find: ‘/run/user/1000/gvfs’: Permission denied
I2C still in blacklist (ERR)
SPI still in blacklist (ERR)
Check for addition in /modules
I2C-dev already there
i2c-bcm2708 already there
spi-dev already there
Hardware revision
gpio version: 2.50
Copyright © 2012-2018 Gordon Henderson
This is free software with ABSOLUTELY NO WARRANTY.
For details type: gpio -warranty
Raspberry Pi Details:
Type: Pi 3B+, Revision: 03, Memory: 1024MB, Maker: Sony
- Device tree is enabled.
*–> Raspberry Pi 3 Model B Plus Rev 1.3 - This Raspberry Pi supports user-level GPIO access.
Check the /dev folder
i2c-1
spidev0.0
spidev0.1
ttyAMA0
USB device status
Bus 001 Device 004: ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device
Bus 001 Device 006: ID 0781:5580 SanDisk Corp. SDCZ80 Flash Drive
Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
|__ Port 2: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
|__ Port 3: Dev 4, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 4, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 4, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 4, If 3, Class=Human Interface Device, Driver=usbhid, 12M
Raspbian for Robots Version
cat: /home/pi/di_update/Raspbian_For_Robots/Version: No such file or directory
Hostname
raspberrypi
Checking for Atmega chip
avrdude: Version 5.10, compiled on Jun 18 2012 at 12:38:29
Copyright © 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright © 2007-2009 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/pi/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : unknown
Using Programmer : gpio
AVR Part : ATMEGA328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 5 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : GPIO
Description : Use sysfs interface to bitbang GPIO lines
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as 5
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as 5
avrdude: safemode: Fuses OK
avrdude done. Thank you.
Checking I2C bus for devices
Checking I2C bus 0
Error: Could not open file /dev/i2c-0' or
/dev/i2c/0’: No such file or directory
Checking I2C bus 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – 04 – -- – -- – -- – -- – -- –
10: – -- – -- – -- – -- – -- – -- – -- – --
20: – -- – -- – -- – -- – -- – -- – -- – --
30: – -- – -- – -- – -- 38 39 – -- – -- – --
40: – -- – -- – -- – -- – -- – -- – -- – --
50: – -- – -- – -- – -- – -- – -- – -- – --
60: – -- – -- – -- – -- – -- – -- – -- – --
70: – -- – -- – -- 76 77
Checking for firmware version
GrovePi has firmware version: 1.4.0
Does the Seed Studio code use the native hardware i2c code, or software i2c?
There is a known issue with hardware i2c on the Pi, especially when driving more than one reasonably high-speed device.
You may wish to experiment with Dexter’s software i2c libraries.
@cyclicalobsessive knows more about this than I can ever hope to know. Hopefully, he’ll drop in and share his wisdom.
I found the issue was with the PIR motion sensor I was using to trigger my assistant. Once I removed that the spikes with the UV stopped. The barometer was still giving odd results, but I don’t really need that for an indoor application. I switched the PIR out with a smartthings device that can trigger it with a webhook.
In terms of Dexter v. Seeed, I’m using a mixture. If I can find something for the GrovePi+ I’ll use it, otherwise I’ll use the Seeed.
Suggest adding additional details and send request (with that troubleshooting log) to support@modrobotics.com
Include port each sensor is plugged into.
Include what language and version you are using.
Include what happens using the Dexter Industries interface to the high accuracy barometer.
Include a link to the software you are using to access the sensors, or better include a copy of the software.
You should understand that if you are using a sensor with the GrovePi which is “not supported”, meaning Dexter Industries has not written (and tested) an interface for the GrovePi to the sensor, you are forging into the unknown where only you will be able to answer your question.
I will always be forging into the unknown because I modify the code on my end to suit my needs. Hence why I ended up solving my own issue.
Right now I think I’m good. I will say that the seeed hats I’ve used elsewhere seem to be a bit more stable. The grovepi+ has always been testy, but I had it lying around for this hydroponics system.
My two centavos here:
I, (my own personal opinion here), look a bit sideways at the Seeed Studio stuff - it’s always been a bit wonky and weird in subtle ways. Maybe they didn’t work, maybe they worked, but in strange and unpredictable ways, or other odd things that were unexplainable.
Back when I was actively involved in Arduino, I bought some Seeed Studio stuff and worked with it:
- Their Arduino clone boards didn’t work with certain shields because of odd component placements - a large capacitor right at the end of one header-strip for example, made certain shields simply not fit at all. Including - oddly enough - even a number of their own shields!
- Board implementation was not standardized to the Arduino baseline - code that would work on Arduino and “standardized” clones would fail in subtle ways on Seeed Studio hardware. In the same way, their shields had oddities in both hardware and software that other shields didn’t have.
- Code examples were strange and it was not unusual to find that they didn’t work, even when installed and run exactly according to their specific instructions. And it wasn’t just me - there was a huge wailing and gnashing of teeth on their fora as well.
- And it wasn’t just one thing - I’d get this board or that board and - every time - there was some wonkyness or weirdness that had to be worked around - and I didn’t have the patience to work around one manufacturer’s oddities when I could buy something from someone else that worked first-time.
- When I used “Genuine” Arduino, (or other manufacturers like SparkFun), I had much less trouble. The examples, (usually), worked, and when they didn’t, the example code got fixed or there was a reasonable reason, and solution, in the forum.
Maybe they’ve improved in the many years that have passed since I worked with them - I don’t know but I sure hope so. What I do know is that I don’t trust them anymore.
Another thing I’ve done in recent time is rank products based on the vitality and helpfulness of their fora. Companies like Dexter and Adafruit come right to the fore, with others like SparkFun and DigiKey a close second. I’ve gotten to the point in my life where I want access to a vibrant, active, and polite forum. Linux Mint is my go-to distribution for just that reason - they have a forum that is second-to-none.
Twenty thumbs up for you!
As @cyclicalobsessive said to me awhile back, part of the mission - IF you choose to accept it - is to Boldly Go where no one has gone before.
Cyclicalobsessive and others are big into pushing the boundaries of AI and autonomous robotics.
Me, I’m just a punter who is learning his way around robotics, messing with the hardware, playing with the (existing) software, trying to learn everything I can, and I am grateful to everyone who has lent me a hand. You would do well to find, and read, everything Cyclicalobsessive has posted. It’s a treasure-trove of tips, tricks, experiments, and good old-fashioned wisdom about programming in general and robotics in particular.
This is true, to some extent, for a lot of Dexter’s stuff.
The main reason, (IMHO), is that the Dexter robots are/were originally designed for a very specific use-case - teaching robotics - and they’re really keen on pushing this stuff into schools and colleges.
Because of this, the Dexter 'bots aren’t really designed to compete with the Arduino maker-space, maker-Pi-bots, SumoBots, Jetson Nano powered bots, bots with multiple Pi boards or a Cray-1 strapped to them, etc.
What is interesting, (and, possibly, unexpected at Dexter), is the surge of hobbyist interest in their products. People like you, Cyclicalobsessive, myself, and others, see in these 'bots something beyond the school-room. What we see is a 'bot that’s eminently capable, modular enough to experiment with, with a good stock software base in both DexterOS and Raspbian for Robots, and all of this at a price that doesn’t require a Federal or DARPA grant to afford.
We’re pushing the boundaries of these robots in ways that Dexter Industries never even imagined in their worst nightmares! Lane following? Autonomous navigation? Used as an AI or vision processing platform? Wow! Who could have imagined it!
Of course, there will be hiccups and oddities. We are - literally - pushing the boundaries of what can be done with these beasties, or other 'bots for that matter.
The folks at Dexter Industries can, and should be, proud of what they’ve accomplished with the robots they offer.
Here are my comments on that topic in another of these fora:
https://forum.dexterindustries.com/t/thinking-about-buying-a-gopigo-go-right-ahead/7390