[polygnwnd]

Could disabling HDMI (add cape disable parameter to u-boot), per https://groups.google.com/forum/#!msg/beagleboard/sIGi77LojUE/NBmoSC9_PlQJ

[polygnwnd]

I am the author on the wireless thread– Edimax Nano wireless adapter is the device in question. Also tried some old dual band Broadcom b43 wifi adapter I had in the parts bin, but it needed even more power and reliably crashed the bone. My BBB is the A6 revision, which is the currently shipping model.

[polygnwnd]

Project shelved for now. I could not get the BBB to run reliably from the onboard 24V AC-DC supply with a USB wireless adapter. Did work OK with wired Ethernet.

[polygnwnd]

If your watering zones dry out proportionately then you can get by with one sensor– this would be the case for an outdoor lawn (full sun areas will be dry before shaded areas, but the relationship between the areas is roughly constant). Probably works well enough for lawns, but a greenhouse with plants at different stages of growth might need more detailed monitoring.

@mike wrote:

There are cheaper moisture meters for maybe £2 or £3 each

My understanding is that there are a few ways to do this. The resistive sensors that are most popular for DIY tend to degrade and/or malfunction over time but are really easy to build (two nails/conductors, and perhaps some gypsum for encapsulation) and simple to understand. I suspect the commercial Toro unit above and 3+6″ commercial versions seen at golf courses use this method (with stainless steel conductors).

The capacitive approach is probably longer-lived, but slightly harder to manufacture. I wonder about the longevity of FR4 PCBs in wet soil, but am curious enough that I might make one and see how it does.

Adafruit is selling a normal atmospheric (air) sensor PCB in some sort of metal housing as a hobbyist soil sensor that looks like a microphone. I wonder if it works/lasts (if it did work/last, why wouldn’t everyone in the industry be burying cheap atmospheric sensor ICs?)

@mike wrote:

Others have found solutions by using moisture sensors to accept or cancel a command sent by a timer. If the command isn’t cancelled (ie when the moisture content is below a low threshold), the timer activates a solenoid valve and irrigation commences.

That’s what the Toro unit does with its relay, it effectively disconnects the zones or actuates the rain sensor input (normally open or normally closed are both supported)

I think there are some interesting demand-driven/wireless sensor-based watering solutions that are now do-able for hobbyist/DIY. The real question is how much savings there is to be found compared to schedule based solutions (and variations: schedule+rain/freeze sensor and schedule+weather forecast) that already manage to deliver enough water. If installed base is a guide, then golf courses (big lawns) are more efficient with sensors. Don’t know much about greenhouses.

[polygnwnd]

Could hack the Toro Xtra Smart Wireless Soil Sensor. It uses the Atmel AT86RF212 900MHz RF chip and costs $45 on eBay (including receiver that contains a PIC and a relay so it can act as a rain sensor for a traditional irrigation controller).

[polygnwnd]

Yes, was measuring AC voltage. It’s probably a badly calibrated multimeter as all the AC voltage readings seem high.

I started with a wired Ethernet cable and 5V DC supply, and things worked well. Switching to wireless took a lot of time, but now I’ve got the wireless drivers working with good reliability.

The issue is that the system seems prone to brown-outs often when running from 24V AC with the USB wireless adapter. System works perfectly (wireless connects and passes traffic without lockups, regardless of CPU load) with a 5V 1000mA DC supply connected directly to the BBB in the same physical location. I’ve replicated this on the bench (short cables) and in the field.

I think I can have 120V AC available where this unit will eventually be installed, so I may just end up with two power supplies– a 24V AC brick for the valves and a 5V power supply connected to the BBB. Is there any problem powering the system with both a 5V brick (connected to BBB) and 24V AC simultaneously? I assume the 5V rail will draw from whatever supply has the higher voltage, but want to confirm that supplying 5V to the BBB will not harm the on-board AC-DC supply.

[polygnwnd]

So the kernel drivers seem awful, and there is a Realtek-supplied driver that works a lot better (at least for me). Latest version seems to be available from https://github.com/pvaret/rtl8192cu-fixes/blob/master/README.md

Setup is well documented elsewhere, but there were some minor variations to make it work on the OSBo image:

1. Install DKMS support for compiled kernel modules

   # build-essential is already on OSBo image
   
   apt-get install dkms 

2. Download precompiled BB headers for OSBo kernel version

   wget http://rcn-ee.net/deb/wheezy-armhf/v3.8.13-bone28/linux-headers-3.8.13-bone28_1.0wheezy_armhf.deb
   
   dpkg --install linux-headers-3.8.13-bone28_1.0wheezy_armhf.deb
   
   

3. Download and install patched driver

   
   
   git clone https://github.com/pvaret/rtl8192cu-fixes.git
   
   dkms add ./rtl8192cu-fixes
   
   dkms install install 8192cu/1.8
   
   # Watch your build fail due to missing timex.h dependency
   
   

4. Edit /usr/src/linux-headers-3.8.13-bone28/arch/arm/include/asm/timex.h on line 18 to change

   #include 

   to

   #include 

   This looks pointless, but allows the build to complete (run dkms install again)

5. Blacklist the native kernel module so the newly compiled module will be used instead

   cp ./rtl8192cu-fixes/blacklist-native-rtl8192.conf /etc/modprobe.d/

6. I’ve also disabled radio power saving as leaving it enabled fills the dmesg log with status messages and causes occasional disconnects from AP. Put the following in a new /etc/modprobe.d/8192cu.conf file

   options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

Obviously these instructions and links/URLs will not age well– they work nicely as of 17 December 2013.

Now ping is not losing packets:

521 packets transmitted, 521 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 2.450/6.857/19.328/1.572 ms

[polygnwnd]

Some more debug info (while connected via wired Ethernet):

uname

root@arm:~# uname -a

Linux arm 3.8.13-bone28 #1 SMP Fri Sep 13 01:11:14 UTC 2013 armv7l armv7l armv7l GNU/Linux

dmesg when USB wifi adapter inserted:

[  188.176953] usb usb1: usb wakeup-resume

[  188.177052] usb usb1: usb auto-resume

[  188.177105] hub 1-0:1.0: hub_resume

[  188.177225] hub 1-0:1.0: port 1: status 0101 change 0001

[  188.281147] hub 1-0:1.0: state 7 ports 1 chg 0002 evt 0000

[  188.281274] hub 1-0:1.0: port 1, status 0101, change 0000, 12 Mb/s

[  188.386435] usb 1-1: new high-speed USB device number 2 using musb-hdrc

[  188.506564] usb 1-1: default language 0x0409

[  188.507427] usb 1-1: udev 2, busnum 1, minor = 1

[  188.507473] usb 1-1: New USB device found, idVendor=7392, idProduct=7811

[  188.507511] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[  188.507545] usb 1-1: Product: 802.11n WLAN Adapter

[  188.507576] usb 1-1: Manufacturer: Realtek

[  188.507608] usb 1-1: SerialNumber: 00xxxx00000x

[  188.511681] usb 1-1: usb_probe_device

[  188.511742] usb 1-1: configuration #1 chosen from 1 choice

[  188.513465] usb 1-1: adding 1-1:1.0 (config #1, interface 0)

[  188.519681] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002

[  188.519802] hub 1-0:1.0: port 1 enable change, status 00000503

[  189.260354] cfg80211: Calling CRDA to update world regulatory domain

[  189.496848] rtl8192cu 1-1:1.0: usb_probe_interface

[  189.496919] rtl8192cu 1-1:1.0: usb_probe_interface - got id

[  189.497346] rtl8192cu: Chip version 0x10

[  189.611075] rtl8192cu: MAC address: 80:1f:02:bb:fe:10

[  189.611153] rtl8192cu: Board Type 0

[  189.611395] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1

[  189.611783] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin

[  189.632273] usbcore: registered new interface driver rtl8192cu

[  189.773844] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'

[  189.786898] rtlwifi: wireless switch is on

lsusb

root@arm:~# lsusb

Bus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

lshw

root@arm:~# lshw -C network -sanitize

*-network:0

description: Ethernet interface

physical id: 1

logical name: eth0

serial: [REMOVED]

capabilities: ethernet physical

configuration: broadcast=yes driver=TI CPSW Driver v1.0 driverversion=1.0 ip=[REMOVED] link=yes multicast=yes

*-network:1

description: Ethernet interface

physical id: 2

logical name: usb0

serial: [REMOVED]

capabilities: ethernet physical

configuration: broadcast=yes driver=g_ether driverversion=29-May-2008 firmware=musb-hdrc ip=[REMOVED] link=no multicast=yes

*-network:2 DISABLED

description: Wireless interface

physical id: 3

bus info: usb@1:1

logical name: wlan1

serial: [REMOVED]

capabilities: ethernet physical wireless

configuration: broadcast=yes driver=rtl8192cu driverversion=3.8.13-bone28 firmware=N/A link=no multicast=yes wireless=IEEE 802.11bgn

lsmod

root@arm:~# lsmod

Module                  Size  Used by

arc4                    1660  2

rtl8192cu              87084  0

rtlwifi                76713  1 rtl8192cu

rtl8192c_common        59545  1 rtl8192cu

mac80211              494605  3 rtlwifi,rtl8192c_common,rtl8192cu

cfg80211              421373  2 mac80211,rtlwifi

rfkill                 18327  1 cfg80211

g_multi                56263  0

libcomposite           17089  1 g_multi

Now bringing up wifi interface

root@arm:~# ifup wlan1

Internet Systems Consortium DHCP Client 4.2.4

Copyright 2004-2012 Internet Systems Consortium.

All rights reserved.

For info, please visit https://www.isc.org/software/dhcp/



Listening on LPF/wlan1/80:1f:02:bb:fe:10

Sending on   LPF/wlan1/80:1f:02:bb:fe:10

Sending on   Socket/fallback

DHCPREQUEST of 192.168.1.180 on wlan1 to 255.255.255.255 port 67 (xid=0x230b0c4f)

DHCPREQUEST of 192.168.1.180 on wlan1 to 255.255.255.255 port 67 (xid=0x230b0c4f)

DHCPREQUEST of 192.168.1.180 on wlan1 to 255.255.255.255 port 67 (xid=0x230b0c4f)

DHCPACK of 192.168.1.180 from 192.168.1.1

bound to 192.168.1.180 -- renewal in 38388 seconds.

dmesg now says

[  744.386533] rtl8192cu: MAC auto ON okay!

[  744.454592] rtl8192cu: Tx queue select: 0x05

[  744.912888] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready

[  747.610632] wlan1: authenticate with [WIRELESS_AP_MAC]

[  747.633050] wlan1: send auth to [WIRELESS_AP_MAC] (try 1/3)

[  747.833633] wlan1: send auth to [WIRELESS_AP_MAC] (try 2/3)

[  748.034804] wlan1: send auth to [WIRELESS_AP_MAC] (try 3/3)

[  748.235955] wlan1: authentication with [WIRELESS_AP_MAC] timed out

[  749.145721] wlan1: authenticate with [WIRELESS_AP_MAC]

[  749.166245] wlan1: send auth to [WIRELESS_AP_MAC] (try 1/3)

[  749.366823] wlan1: send auth to [WIRELESS_AP_MAC] (try 2/3)

[  749.567988] wlan1: send auth to [WIRELESS_AP_MAC] (try 3/3)

[  749.769168] wlan1: authentication with [WIRELESS_AP_MAC] timed out

[  750.674845] wlan1: authenticate with [WIRELESS_AP_MAC]

[  750.696906] wlan1: send auth to [WIRELESS_AP_MAC] (try 1/3)

[  750.898088] wlan1: send auth to [WIRELESS_AP_MAC] (try 2/3)

[  751.099271] wlan1: send auth to [WIRELESS_AP_MAC] (try 3/3)

[  751.300425] wlan1: authentication with [WIRELESS_AP_MAC] timed out

[  752.208067] wlan1: authenticate with [WIRELESS_AP_MAC]

[  752.229125] wlan1: send auth to [WIRELESS_AP_MAC] (try 1/3)

[  752.429323] wlan1: send auth to [WIRELESS_AP_MAC] (try 2/3)

[  752.630493] wlan1: send auth to [WIRELESS_AP_MAC] (try 3/3)

[  752.831660] wlan1: authentication with [WIRELESS_AP_MAC] timed out

[  753.748137] wlan1: authenticate with [WIRELESS_AP_MAC]

[  753.768598] wlan1: send auth to [WIRELESS_AP_MAC] (try 1/3)

[  753.772072] wlan1: authenticated

[  753.775149] wlan1: associate with [WIRELESS_AP_MAC] (try 1/3)

[  753.789979] wlan1: RX AssocResp from [WIRELESS_AP_MAC] (capab=0x431 status=0 aid=1)

[  753.791445] wlan1: associated

[  753.791551] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready

iwconfig after a minute or so:

root@arm:~# iwconfig wlan1

wlan1     IEEE 802.11bgn  ESSID:"[MY_NETWORK_SSID]"

Mode:Managed  Frequency:2.462 GHz  Access Point: [WIRELESS_AP_MAC]

Bit Rate=72.2 Mb/s   Tx-Power=20 dBm

Retry  long limit:7   RTS thr=2347 B   Fragment thr:off

Encryption key:off

Power Management:off

Link Quality=70/70  Signal level=-35 dBm

Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

Tx excessive retries:0  Invalid misc:12   Missed beacon:0

[polygnwnd]

Basically you can tie it into the BBB’s soft power button (it’s on the BBB header) so the RTC powers the bone on whenever the alarm is programmed to fire (alarm times are programmable via I2C). This could be useful if you want to run the controller with battery/solar power, and wake the bone before the next scheduled event. For instance you could have the BBB power off overnight (or when solar input voltage drops below a threshold), between scheduled events, etc.

Used this method for a project last summer.

[Author]

Posts