Send Bristol mailing list submissions to
bristol@mailman.lug.org.uk
To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.lug.org.uk/mailman/listinfo/bristol
or, via email, send a message with subject or body 'help' to
bristol-request@mailman.lug.org.uk
You can reach the person managing the list at
bristol-owner@mailman.lug.org.uk
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bristol digest..."
Today's Topics:
1. Re: Opamp - somewhat off topic (Allen Coates)
2. Re: Slony probs (Martin Moore)
3. Re: Slony probs (Colin M. Strickland)
4. Re: Slony probs (Martin Moore)
5. Re: Slony probs (Martin Moore)
6. Re: Opamp - somewhat off topic (david)
----------------------------------------------------------------------
Message: 1
Date: Tue, 25 Feb 2014 12:04:02 +0000
From: Allen Coates <linux@cidercounty.org.uk>
To: Bristol and Bath Linux User Group <bristol@mailman.lug.org.uk>
Subject: Re: [bristol] Opamp - somewhat off topic
Message-ID: <530C86B2.3060006@cidercounty.org.uk>
Content-Type: text/plain; charset=ISO-8859-1
Dave SMITH wrote:
> On 25/02/2014 01:35, Allen Coates wrote:
>> The open-loop gain of an opamp is (theoretically) infinite - in practice
>> tens of thousands. You set the stage gain using feedback resistors.
>>
>> If you amplify an analogue signal 400 times, I have a feeling you would
>> encounter problems with input noise.
>>
>> It may be better to use the opamp as a comparator, where the output is
>> logic zero if the input is below an (adjustable) threshold level, and
>> logic one if it is above. Two such comparators would give you a clear
>> Low/Acceptable/High indication.
>
> Good point, and you could then feed the result into a digital IO rather
> than needing an analogue input.
>
> I'm not sure I'd do a comparator at such low voltages, though - after
> all, the obvious way to generate the threshold voltage would be through
> a resistive voltage divider, but even if you use resistors with 1%
> tolerance (about the limit of what is widely available), you're still
> going to end up with a threshold that could vary by as much as 1000%.
I haven't played with load cells, but with strain gauges you would use a
pair of them - or a "rosette" - in a bridge type circuit. It was even
possible to stress one gauge in compression, and its partner in tension
to double the output from the bridge...
> To do the design "right", I think I'd have a first OpAmp stage with a
> gain of somewhere around 20 (giving you a voltage swing of about 100
> mV), and then feed that into a comparator.
I thought of that - just after I had pressed the <SEND> key...
> To make things even better, you could even use a voltage reference IC as
> the input to the voltage divider, so that you get a nice stable supply
> that's not wandering around as the Pi power consumption changes.
> Reference ICs generating a 1.2 V output are cheap (about 30p from RS)
> and readily available, and you'd only need one across all your channels.
Bridges tend to be insensitive to supply voltage fluctuations - but
you're right. Every little helps. I must admit, though, I like "tuning
for zero" on a ten turn pot.
------------------------------
Message: 2
Date: Tue, 25 Feb 2014 14:27:02 -0000
From: "Martin Moore" <martinm@it-helps.co.uk>
To: "'Bristol and Bath Linux User Group'" <bristol@mailman.lug.org.uk>
Subject: Re: [bristol] Slony probs
Message-ID:
<!&!AAAAAAAAAAAYAAAAAAAAAFLxZtQqo65Oo+1jhlUB9DvCgAAAEAAAAH8v8vI3hs5Mv+9gUvbSR5gBAAAAAA==@it-helps.co.uk>
Content-Type: text/plain; charset="us-ascii"
Almost got londiste running - but guess what :
londiste jess2sb3.ini provider install
2014-02-25 14:08:14,472 16014 INFO plpgsql is installed
2014-02-25 14:08:14,474 16014 INFO txid_current_snapshot is installed
2014-02-25 14:08:14,474 16014 INFO pgq is installed
2014-02-25 14:08:14,475 16014 INFO Installing londiste
2014-02-25 14:08:14,475 16014 INFO Reading from
/usr/share/skytools/londiste.sql
Traceback (most recent call last):
File "/usr/bin/londiste", line 134, in <module>
script.start()
File "/usr/bin/londiste", line 97, in start
self.script.start()
File "/usr/lib/python2.7/dist-packages/skytools/scripting.py", line 369,
in start
run_single_process(self, self.go_daemon, self.pidfile)
File "/usr/lib/python2.7/dist-packages/skytools/scripting.py", line 98, in
run_single_process
runnable.run()
File "/usr/lib/python2.7/dist-packages/londiste/setup.py", line 73, in run
self.admin()
File "/usr/lib/python2.7/dist-packages/londiste/setup.py", line 176, in
admin
self.provider_install()
File "/usr/lib/python2.7/dist-packages/londiste/setup.py", line 227, in
provider_install
self.exec_provider(q, [self.pgq_queue_name])
File "/usr/lib/python2.7/dist-packages/londiste/setup.py", line 359, in
exec_provider
src_curs.execute(sql, args)
File "/usr/lib/python2.7/dist-packages/psycopg2/extras.py", line 123, in
execute
return _cursor.execute(self, query, vars)
psycopg2.ProgrammingError: operator is not unique: unknown || integer
LINE 1: SELECT 'pgq.event_' || id
^
HINT: Could not choose a best candidate operator. You might need to add
explicit type casts.
QUERY: SELECT 'pgq.event_' || id
CONTEXT: PL/pgSQL function pgq.create_queue(text) line 34 at assignment
So, I hacked 2 of the pqc functions to cast 'id' to int and all is ok. But
only needed to do this on the provider, not the subscriber. I think there's
something odd with the setup on the provider which was the cause of the
slony problems.
I'll try and find out what's going wrong.
-----Original Message-----
From: bristol-bounces@mailman.lug.org.uk
[mailto:bristol-bounces@mailman.lug.org.uk] On Behalf Of Colin M. Strickland
Sent: 24 February 2014 22:26
To: Martin Moore; Bristol and Bath Linux User Group
Subject: Re: [bristol] Slony probs
On 24 Feb 2014, at 22:06, Martin Moore wrote:
> I'll check out skytools londiste - I only want some tables replicated,
> so can't use the built-in stuff.
Londiste is ideal for this use, (as is slony of course). It's more
lightweight, and I found it more easy to troubleshoot. I replaced the slave
db servers at last.fm replicating a couple of 100GB of catalogue metadata
via slony-1 on pg 8.3 with londiste and pg 9.1 a year or so ago, and found
the migration process fairly painless.
The most significant difference was that the londiste slaves don't enforce
any kind of read-only state on the replica tables, so I had to manage that
with user access control (I used pgbouncer to map any incoming tcp/ip
database connection down to a user with no write access)
Rather than loading scripts into the slightly cranky slonik command parser,
you just interact with the replication agent using command line tools from
the shell - "londiste subscriber add tablename" etc.
--
Regards,
Colin M. Strickland, cms, 'that guy'.
_______________________________________________
Bristol mailing list
Bristol@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/bristol
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4335 / Virus Database: 3705/7092 - Release Date: 02/14/14
Internal Virus Database is out of date.
------------------------------
Message: 3
Date: Tue, 25 Feb 2014 14:44:00 +0000
From: "Colin M. Strickland" <cms@beatworm.co.uk>
To: "Martin Moore" <martinm@it-helps.co.uk>, "Bristol and Bath Linux
User Group" <bristol@mailman.lug.org.uk>
Subject: Re: [bristol] Slony probs
Message-ID: <BCB5DB59-5D67-4D01-97AB-9E30EAE12D9B@beatworm.co.uk>
Content-Type: text/plain; format=flowed
On 25 Feb 2014, at 14:27, Martin Moore wrote:
> psycopg2.ProgrammingError: operator is not unique: unknown || integer
> LINE 1: SELECT 'pgq.event_' || id
> ^
> HINT: Could not choose a best candidate operator. You might need to
> add
> explicit type casts.
> QUERY: SELECT 'pgq.event_' || id
> CONTEXT: PL/pgSQL function pgq.create_queue(text) line 34 at
> assignment
This is the same category of error as before. I would expect the
database to just know how to cast integers to strings. Do you get an
exception thrown if you run something like this on the provider ?
postgres=# select 123 || ' a string ' as demonstration ;
demonstration
---------------
123 a string
(1 row)
Your database seems a bit confused about basic types and operators in a
way I find surprising.
--
Regards,
Colin M. Strickland, cms, 'that guy'.
------------------------------
Message: 4
Date: Tue, 25 Feb 2014 14:55:51 -0000
From: "Martin Moore" <martinm@it-helps.co.uk>
To: "'Bristol and Bath Linux User Group'" <bristol@mailman.lug.org.uk>
Subject: Re: [bristol] Slony probs
Message-ID:
<!&!AAAAAAAAAAAYAAAAAAAAAFLxZtQqo65Oo+1jhlUB9DvCgAAAEAAAAFlbBE6YKl5Ls4Q2aOxyibwBAAAAAA==@it-helps.co.uk>
Content-Type: text/plain; charset="us-ascii"
select 123 || ' a string ' as demonstration ;
does indeed fail. So, I removed the cast/function I added to get 8.4 working
and it bursts into life. Obviously some work has been done on autocasting
between 8.4 and 9.3!!
I'll try slony again as we have no experience of londiste, although it does
look god.
-----Original Message-----
From: bristol-bounces@mailman.lug.org.uk
[mailto:bristol-bounces@mailman.lug.org.uk] On Behalf Of Colin M. Strickland
Sent: 25 February 2014 14:44
To: Martin Moore; Bristol and Bath Linux User Group
Subject: Re: [bristol] Slony probs
On 25 Feb 2014, at 14:27, Martin Moore wrote:
> psycopg2.ProgrammingError: operator is not unique: unknown || integer
> LINE 1: SELECT 'pgq.event_' || id
> ^
> HINT: Could not choose a best candidate operator. You might need to
> add explicit type casts.
> QUERY: SELECT 'pgq.event_' || id
> CONTEXT: PL/pgSQL function pgq.create_queue(text) line 34 at
> assignment
This is the same category of error as before. I would expect the database to
just know how to cast integers to strings. Do you get an exception thrown if
you run something like this on the provider ?
postgres=# select 123 || ' a string ' as demonstration ;
demonstration
---------------
123 a string
(1 row)
Your database seems a bit confused about basic types and operators in a way
I find surprising.
--
Regards,
Colin M. Strickland, cms, 'that guy'.
_______________________________________________
Bristol mailing list
Bristol@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/bristol
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4335 / Virus Database: 3705/7092 - Release Date: 02/14/14
Internal Virus Database is out of date.
------------------------------
Message: 5
Date: Tue, 25 Feb 2014 15:09:11 -0000
From: "Martin Moore" <martinm@it-helps.co.uk>
To: "'Bristol and Bath Linux User Group'" <bristol@mailman.lug.org.uk>
Subject: Re: [bristol] Slony probs
Message-ID:
<!&!AAAAAAAAAAAYAAAAAAAAAFLxZtQqo65Oo+1jhlUB9DvCgAAAEAAAAM3MIlbldE1LkZaHY9uVa9kBAAAAAA==@it-helps.co.uk>
Content-Type: text/plain; charset="us-ascii"
Slony has now installed OK. (at least without errors!).
Thanks for your help - that must be the hardest way to find out why slony
wasn't installing....
Martin.
-----Original Message-----
From: bristol-bounces@mailman.lug.org.uk
[mailto:bristol-bounces@mailman.lug.org.uk] On Behalf Of Colin M. Strickland
Sent: 25 February 2014 14:44
To: Martin Moore; Bristol and Bath Linux User Group
Subject: Re: [bristol] Slony probs
On 25 Feb 2014, at 14:27, Martin Moore wrote:
> psycopg2.ProgrammingError: operator is not unique: unknown || integer
> LINE 1: SELECT 'pgq.event_' || id
> ^
> HINT: Could not choose a best candidate operator. You might need to
> add explicit type casts.
> QUERY: SELECT 'pgq.event_' || id
> CONTEXT: PL/pgSQL function pgq.create_queue(text) line 34 at
> assignment
This is the same category of error as before. I would expect the database to
just know how to cast integers to strings. Do you get an exception thrown if
you run something like this on the provider ?
postgres=# select 123 || ' a string ' as demonstration ;
demonstration
---------------
123 a string
(1 row)
Your database seems a bit confused about basic types and operators in a way
I find surprising.
--
Regards,
Colin M. Strickland, cms, 'that guy'.
_______________________________________________
Bristol mailing list
Bristol@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/bristol
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4335 / Virus Database: 3705/7092 - Release Date: 02/14/14
Internal Virus Database is out of date.
------------------------------
Message: 6
Date: Tue, 25 Feb 2014 19:04:46 +0000
From: david <david@avoncliff.com>
To: bristol@mailman.lug.org.uk
Subject: Re: [bristol] Opamp - somewhat off topic
Message-ID: <530CE94E.3050807@avoncliff.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 24/02/14 12:44, Andrew wrote:
> We are using a load cell to measure the amount of ink. It gives an
> output of about 5 mV. As stated by a helper "The input range on the
> Custard Pi 3 is from 0 to 2.5V. So to get the best accuracy from this
> load cell, we need an amplification of around 400 using an opamp."
I am coming a bit late to this conversation, but the Raspberry does not
have an analogue to digital input. I am not sure what they are referring
to on the Custard, but I guess that is the range of volts the digital
ports can cope with.
I would recommend using an external A->D chip, and selecting one that
has the accuracy you need at low voltage. Maybe still with low gain
amplifier, say 10x. Try search "precision fixed gain op amp"
Search "Raspberry Analogue Input" gives plenty of hits.
( I am sure I have got some 40 year old 741's around here somewhere )
David
------------------------------
_______________________________________________
Bristol mailing list
Bristol@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/bristol
End of Bristol Digest, Vol 539, Issue 8
***************************************
Tidak ada komentar:
Posting Komentar