Showing posts with label Controls. Show all posts
Showing posts with label Controls. Show all posts

Saturday, October 15, 2022

 Garden watering system.

I will be away for a few days and the seedlings can't be let to get dry at this time of the year. Not much time and I as always work on a budget:  Reviewed the timer tap controllers and sprinklers. Picked a controller from Jaycar and tried a rotating lawn sprinkler.

I thought if the timer software is not good but the hardware is Okay I might gut it and replace it's brains with a Arduino type controller then get all sorts of remote control. The hardware seems fine so far though and the software too. Lets leave it at that for now.

The lawn sprinkler just did not work and stuck after half an oscillation. I returned it an got a simple cone spray that is meant to stick in the lawn. I mounted it upside-down over the main garden and used the timer to set it running for 15 minutes at 6 am and 6 pm. It seems just fine for late spring and did a great job while I was away for 5 days.

Control unit and sprinkler.
 

I might tap into the hose that runs along side of the house with some screw in spray nozzles to water some potted plants to the along there. I put these pots in the empty spots of the garden under the timed sprinkler while I was away and that worked out well but I need that space to let things grow so the pots need to go back.

Then
Now


Saturday, February 28, 2015

2015-02 Control surface for audio processing

I've been considering a sound processing language for a while. Looked at supercollider and liked it but never really did anything with it. Tried again recently and found chuck. I had a play and liked it. Not sure why I prefer it but it's something like: less elegant but faster to code.
The missing bit was an interface so effects and apps writen in chuck could be conveniently controlled during performance or production.
Found interface.js which can use OSC to send messages to any osc aware system/program (which chuck is) and has a constrained but easy to use way to build a panel of controls. These panels are accessed as web pages served by an included server so a tablet can access it.
Presto:  The knobs, sliders and buttons are all touch sensitive on the tablet and you have a versatile touch sensitive control surface that can talk to chuck.

Details follow:

Notes on installing chuck.
I use Fedora both 20 and 21 on two different machines with the CCRMA repo (CCRMA fed21 repo here) with:

       sudo dnf install chuck
       sudo dnf install miniaudicle

The standard packages seem OK.  ( I did build from source to try to fix the windows in miniAudicle not remembering their locations between sessions: got bogged down in QT, but the build was process was reasonable )
The way I use it is to start  jack (with qjackctl) then run miniAudicle.
You'll get an IDE, a console window (shows error, information and print type debug messages) and an execution control window (called Virtual Machine). Like this:
The doc's are a bit out of date for the osc stuff but  these examples are current and will set you right.
You start the virtual machine then use the IDE to edit and run code. Lots of good examples to play with in the link above. (you don't have to use jack: there's  miniAudicle-pulse and miniAudicle-alsa if it suits you better)
Update: Nearly there. A bit stuck on the OSC stuff and chuck keeps locking the osc message stream. Nuts.

Tuesday, October 12, 2010

2010-10 IR Menus system

The OSD tools I'd used for the IR control menu have bit rotted, are too slow and not good looking.
Get a simple, fast image based menu going. Theme-ability is a bonus.

Sunday, September 12, 2010

2010-09 Stereo patch bus

Tired of plugging in various new devices for recording or playback. It's a chore and messy to the point where I'm deferring audio projects on account of it.
Some simple patch panels to allow selecting / routing inputs and out puts are needed.

Thursday, June 26, 2008

2008-06 PC Infra-red Remote

After last months project burn-out I wanted a simple P.T.O.M. this time. I've started using the TV card on the PC and watching vcds etc on my PC. The TV card(s) both came with remotes and in these cold winter nights lying on the sofa these could be useful.
So how hard can it be? and the IR can control all sorts eh? oxine looked great for example so that was it. Get IR control going in the POTM.

LIRC seems to be the main project here. It looks like it supports both of the TV cards I have, One SAA7134 based and one BT878 based.

It goes: A Real Quick Run-down for fedora 9.
  • Set up the remote: Install the IR drivers and lirc. Use irrecord to create a config file for your remote control and copy it to /etc/lircd.conf.
  • Get lircd running. Configure /etc/sysconfig/lirc to use the right driver for you and then lircd to start on system boot like any daemon. (use the /dev/input/by-path device if you use devinput as the device driver. Don't use /dev/input/eventX as X can change on reboot)
  • edit (and create if necessary) ~/.lircrc. Check the application you want to control for details on lirc commands and match the commands to the keys in ~/.lircrc
  • use irexec if needed. It will trigger things if the app you wan't to control isn't looking at lircd for events itself. For example; tvtime needs irexec but gnome-radio does not. I use gnomes session management to run this.

OK What happened in detail:
First it had to track down the parts; The remote controls and the IR sensors. Found the remotes. Now check that they remotes both work aftre years in storage.
I recall a note in Silcon Chips serviceman pages saying you can check IR by looking for the IR led in a CCD device.

IE by looking at them with a web cam or digital camera and that works: Off and On.
Both remotes are good and so are their batteries.
Kinda ghostly seeing one thing in the view finder and another with your eyes.

Now find the IR sensors. Both found (yeah for my pack-rat self) and the different plugs mean it's clear that which sensor is for which card.

OK plug in the sensor and let's try to get IR control going on the existing card in my desktop PC.

Nothing. OK, check the module options for the card; I was never that sure they were right even thought the seemed to work OK with BT878 card. Check the PCI ID and find it could be one of three so try them all:

options bttv card=30 #Seems OK. No IR. The value I have been using.
options bttv card=39 #Video OK. No sound, no IR, snd_BT87x won't help with sound.
options bttv card=52 #Video OK. No sound, no IR, snd_BT87x won't help with sound.

OK that's not getting me anywhere, lets try the SAA7134 card from gnabgib. I think that was more upmarket and I've bumped into reassuring references to them while checking the LIRC docs.

Fire up gnabgib which is the machine that the card had last been used in (mothballed right now) and check the existing config (from memory it worked OK, never tried the IR though, only really used the FM card for the Concert and National stations):

relevant Modules loaded on gnabgib:
saa7134 110741 0
video_buf 23365 1 saa7134
v4l2_common 5825 1 saa7134
v4l1_compat 13125 1 saa7134
i2c_core 21825 2 tuner,saa7134
ir_common 7493 1 saa7134
videodev 9537 1 saa7134
soundcore 10529 2 saa7134,snd

relevant modprobe.conf line from gnabgib:
alias char-major-81 saa7134

Log from gnabgib of saa7134 loading:
kernel: saa7130/34: v4l2 driver version 0.2.12 loaded
kernel: saa7134[0]: quirk: PCIPCI_TRITON
kernel: saa7134[0]: found at 0000:00:04.0, rev: 1, irq: 11, latency: 66, mmio: 0x41080000
kernel: saa7134[0]: subsystem: 5168:0138, board: LifeView FlyVIDEO3000 [card=2,autodetected]
kernel: saa7134[0]: board init: gpio is 39000
kernel: saa7134[0]: there are different flyvideo cards with different tuners
kernel: saa7134[0]: out there, you might have to use the tuner= insmod
kernel: saa7134[0]: option to override the default value.
kernel: saa7134[0]: registered input device for IR
kernel: saa7134[0]: i2c eeprom 00: 68 51 38 01 10 28 ff ff ff ff ff ff ff ff ff ff
kernel: tuner 0-0061: chip found @ 0xc2 (saa7134[0])
kernel: tuner 0-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
kernel: saa7134[0]: registered device video0 [v4l2]
kernel: saa7134[0]: registered device vbi0
kernel: saa7134[0]: registered device radio0
kernel: saa7134[0]/audio: audio carrier scan failed, using 5.500 MHz [default]

OK, pull the card out.

Card label info:
DSE PCI TV Tuner Card XH6765

Well, that just worked. No config nothing: I thought I'd just try the remote to see and the volume and channel numbers worked on both remotes.

(Later I understood that this is becase lirc creates a fake keyboard that sends keystrokes matching keycodes of a real keyboard so numbers, enter key and volume all worked as though the keystroke came from the keyboard. I think the vol worked becase it emulates those odd-arsed mutlimedia keys )

Events are commint in on /dev/input/event7 so I'll look at irc now and see if I
can get things going more generally.

After reboot it was event6. Then on the next reboot event7 again . Himmm...

OK: Created a profile for the remote with irrecord - painless - and moved it to
/etc/lircd so that the keys are recognised and have names that mean something.

Set up /etc/sysconf/lirc.conf to tell it to use event7.

Got stuck then. Created a test ~/.lircrc for tvtime but nothing.
read read read...
OK tvtime is not a client itself. Run irexec as a daemon which connects to lirc as a client and then ~/.lircrc will be used by it and any revient lines executed.
NOTE it seems that as soon as a vaild client connects the fake keystrokes are no
longer available.

Beaut mate.