Show Posts
Pages: [1] 2 3
1  Development / Other Software Development / Re: b0 or b7, that is the question. on: May 25, 2014, 08:22:56 am
Lowest. Always.

Thanks again. That'll hold me for at least a Byte bit.
2  Development / Other Software Development / Re: b0 or b7, that is the question. on: May 24, 2014, 09:51:33 am
b0 is the right hand bit, b7 is the left hand bit.
First statement is wrong as posted.

Thanks CrossRoads and by the same token,  is the lowest numbered pin always the LSB in a direct port read or are some ports contrary on the various Arduinos?
3  Development / Other Software Development / b0 or b7, that is the question. on: May 23, 2014, 07:43:00 am
This page holds what look to me like contradictions and so I thought I'd flag it up.

My assertion stems from these two lines:
...So if we write PORTD = B00110001; we have made pins 2,3 & 7 HIGH...
DDRD = DDRD | B11111100; // set direction bits for pins 2 to 7, leave 0 and 1 untouched (xx | 00 == xx)

Would be grateful for enlightenment - thanks.
4  Using Arduino / Sensors / Re: Opamp - is this a floating problem on: January 21, 2013, 04:49:30 am
MarkT thanks.

So the line that reads: Power Supply Voltage Range ±2.5V to ±17V indicates that it must go from negative to positive - presumably in approx equal measure.

Although I have poured over many examples in my quest to understand opamps, I don't yet know how to make the evaluation you make here:
For a 1M impedance it would be a 7mV error, for 1k impedance only 7uV (well below the input offset spec of 50uA)
and I'll make it my next aim.

Would a negative regulator be useful such as the ICL7660SCPAZ found here:

Thanks for your help.

5  Using Arduino / Sensors / Re: Opamp - is this a floating problem on: January 20, 2013, 01:36:21 pm
There are no diagrams as such for comparator circuits but for those circuits shown, some have resistors to ground and some don't.  I would take this to mean it depends upon other criteria.

For the sensor, no such information is given.  My suspicion was aroused by a question I posed to the manufacturer, at which point they said the analogue output was completely independant of the voltage in.  I took this to mean that the resulting signal was created from a light sensitive component of sorts and without boosting - but 2.0V sounds a lot and so I now question this.

The datasheet page is:

6  Using Arduino / Sensors / Opamp - is this a floating problem on: January 20, 2013, 10:57:43 am
I have an odd problem involving a LME49710 opamp.  I am developing my circuit to light up a particular LED based on a comparitor funcion (the opamp).  My circuits' supply is the 5V regulated Arduino output and the grey-scale sensor typically outputs between 0.2V and 2.0V.

I choose (set) the reference on the '-' pin using a 500k linear pot. The sensor is wired straight to the '+' pin without any pull down resistor etc.  All seems basically ok but regardless of the chosen voltage reference point (this depends upon the greyscale value under the sensor) the pot is always at very nearly full tilt - where the voltage returned is about zero - ie nearly grounded.

Do I need a pull down resistor to stop the sensor floating or...

Thanks a lot
7  Using Arduino / Project Guidance / Re: SICK sensor and AD wobble on: October 21, 2012, 04:09:45 am
The only one I've had first hand experience with on a arduino is the TI ADS1115 16 bit 4 channel (or 2 differential channels).

I have a check out sketch code available if you actual try one of these out.


I'd like that please Lefty, I've plunged.  Thanks a lot 2Tricky.
8  Using Arduino / Project Guidance / Re: SICK sensor and AD wobble on: October 21, 2012, 04:03:30 am
It sounds as if, as well as being at the limit of how accurately it's feasible to measure an analog signal, you're also at the limit of how frequently you can take those measurements. This is not encouraging, and you may be constraining yourself into an intractable problem. I still feel that using a single brightness reading requires that reading to have unrealistically fine resolution and interpolating from multiple readings would enable you to get a better resolution.

One way to relax the precision requirements would be to reduce the size of the scanned area. That would mean you have even stricter requirements to get the scanner positioned in the right place and I don't know whether that's feasible.

Is it possible to give a more general explanation of what you're trying to achieve and what overall system this solution has to fit within? It may be possible to apply some lateral thinking, such as applying a vernier technique using multiple sensors, but without any idea what the thing is you're trying to measure the position of, it's hard to know where to start.

As often is the case, this project is relative to how things are currently which is without any feedback or automatic control at all.  It would be a shame for the final prognosis to be way under ambition but I don't expect that to happen...

The light 'spot' from these eyes looks something like 4mm x 1.2mm (fuzzy edges) and my experiments have placed the spot so that 4mm x 0.6mm is on one colour and 4mm x 0.6mm is on the other and a 0.5mm image movement would not in principle change this.  Unfortunately, turning the sensor through 90 degrees would transform the available sampling 'window' but wouldn't be possible most of the time because the images will not always extend far enough, which is a prerequsite of a linear greyscale to position formula. Another unfortunate byproduct is a worse position resolution relative to greyscale (albeit potentially linear) for any image regardless (we can't win).

You mentioned the accuracy of sensor placement in an earlier post and I think it is worth mentioning that it is not important to put the sensor exactly half on half off the image and this is because only a 'piece of string' reference is required i.e. the inital value will become the 'ideal' and any wander is an error.  Ultimately a mV:position ratio will be used to provide user friendly info and of course for any automatic correction (another project using steppers perhaps - I'm excited).

N.B. The current guise takes the first n readings and provides a plot of both extremes and the mean average over which the ADC output is ploted.

I am pleased to say that I have ordered the 1115 chip/breakout that Lefty suggested because I have to get my hands dirty with electronics per se and think it will be instructive to observe the outcome for our project using our hardware in our environment etc.  I hasten to add, this project suits me down to the ground - I've always wanted to marry up programming and machinery and get into electronics proper.  I'm trying to learn DesignSpark too (now V4) with varying success.

Thanks peterH
9  Using Arduino / Project Guidance / Re: SICK sensor and AD wobble on: October 19, 2012, 04:17:49 am
Lefty I am probably getting the TI ADS1115 chip you mentioned but also found a thread here where 'oversampling and decimation' was discussed.

Is this worth considering or... From my point of view, I am aware that 2ms delay is suggested between analogue reads and then there is a 100µs or so required for an interrupt and would be grateful if you were able to comment.

Unfortunately I am very aware that the opportunity for oversampling is limited - in an earlier post I suggested that one shot is only possible, but needs must where the devil drives.

Here is the maths assuming a 0.5mm maximum permitted image travel 'window' (it is assumed that the image would not change shape beneath the sensor during this time):
Minimum speed... 20 feet per min = 6096mm per min
Time elapsed for 0.5mm travel... 4.92ms ±

Earlier I indicated that there would be 1mm of 'constant' image available and here I take 0.5mm to be the maximum.  Fact is, it is as long as a bit of string in that sometimes 0.5mm might not be available and so I have to play devils advocate.

Another aspect that I am aware of is the permitted frequency of AD reads from this chip and wonder whether, given that there will be an interrupt overhead too (Arduino), and that it will then issue commands over the bus and that the I2C bus is not the fastest (V4 doesn't seem to be available on this chip), will this scupper it?

I am clearly looking at the minutiae, which is not always the best route, but please comment if you have a view.

Thanks again.
10  Using Arduino / Project Guidance / Re: SICK sensor and AD wobble on: October 19, 2012, 03:28:04 am
I don't know your setup that well but if you are using dividers or voltage references, think about what kind of resistors /Vref you will need in order to maintain the comparability of 16-bit adc from source to source.

dhenry, I'm slowly working out the route of least resistance (metaphorically) and going over something you said...

Would you be able to explain what your references above mean - thanks.
11  Using Arduino / Project Guidance / Re: SICK sensor and AD wobble on: October 18, 2012, 11:03:47 am
As mentioned, 0.01mm per integer from the ADC is adequate, but 0.1mm isn't.

I don't know what exactly you are trying to achieve but 0.1mm seems to be well below what a (untrained) human eye can detect.

Maybe you want to step back and see the minimum resolution / accuracy required and what that corresponds to a voltage signal for your adc and go from there.

I posted a little explanation of how the error can be magnified just now if you get a chance to read it but I'll do a little working backwards as you suggest too.

Thanks a lot.
12  Using Arduino / Project Guidance / Re: SICK sensor and AD wobble on: October 18, 2012, 10:19:22 am
Lefty I appreciate that but I'm sorry to say I have even shallower pockets than that - of course I have to get it here too.  I'll see if I can get something for the fluff!
13  Using Arduino / Project Guidance / Re: SICK sensor and AD wobble on: October 18, 2012, 09:45:25 am
..Is it correct that you're using the dark/light contrast to find the position of a boundary between dark and light parts of an image?

That's right.

How accurately can you position the sensor? Is it feasible to scan the sensor across the boundary? If so, I suspect you could get a much more precise position for the boundary by interpolating the position of the '50%' brightness point from a sequence of brightness readings in different positions rather than needing a single brightness reading to give you a hugely precise measurement of the proportion of dark/light areas within the image.

Unfortunately 'not really' possible given that a big problem would be the inertia in the hardware used to accomplish a scan.  The material is moving at speeds of 20 fpm minimum (can be much faster) but in the direction that everything being equal (which of course cannot be so) will give a constant reading over the time taken to examine the analogue pin i.e. along the threshold of the two colours.  Hence there is really just one shot possible and it has to be the best effort.  In the current guise, a chart plots the result along the X axis as time passes.

I hasten to add: I have lashed together a temporary complete system to test the reliability of using a moving target and the result is indistinguishable from a completely stationary image and so I have no worries with a moving target in principle.  I should also mention: The duration that a consistent image will be available for under the sensor is as long as a piece of string in that it could start to be very different within say 1mm movement (prorata time elapsed and speed).

Thanks a lot PeterH
14  Using Arduino / Project Guidance / Re: SICK sensor and AD wobble on: October 18, 2012, 08:11:52 am
TI ADS1115 16 bit

Let me be the first to say that unless you are a very good engineer, using a 16-bit adc can be quite a challenge. And unless you are some analog god, using a 24-bit adc can be downright impossible.

Rather than increasing the bits, you should think if you need that much resolution and if that high of a resolution makes sense for your application (for example, is it even that accurate?).

dhenry I think it will help if I clarify with a bit more context: The best scenario from the ratio of the 'image movement to ADC output' point of view is using the red light and comparing white with black marks. The technique used (so far) places the light half on one colour and half on the other colour, which provides the average greyscale as output.  To move from fully on one colour to fully on the other the image needs to travel around 1.5mm which provides less and less resolution the lower the relative greyscale values get.

As mentioned, 0.01mm per integer from the ADC is adequate, but 0.1mm isn't.  For example: If a small sheet (all sides are in centre vision) of paper has a black border of say 1mm, and a 0.1mm error occurs along one axis, one side will become 0.9mm and the other 1.1mm, meaning the smaller will be nearly 20% smaller which humans can see quite easily and may or may not hurt sensibilities (depending upon the nature of the onlooker!) and this assumes the conversion is accurate and doesn't suffer from noise etc.

It is also worth noting that my current quest is to measure any error rather than applying any correction (I'm treating subsequent correction as incidental).

You've got me worried though and I would appreciate some detail if you are in the position to do so...Thanks a lot
15  Using Arduino / Project Guidance / Re: SICK sensor and AD wobble on: October 18, 2012, 05:26:50 am
Lefty I'm amazed at how small the chip is, no wonder it's offered with a breakout board.  Do you happen to know of one that might be attachable to a breadboard so that I can experiment cheaply.  I appreciate that this is the only one familiar to you in an Arduino context, but guessing that I2C is I2C is I2C (unless perhaps it's revision 4 - I don't know) and provided I can get insight into the 'quality' of the chip, perhaps I could use another without much code change...

N.B. I have now tested the current AREF setup with a 12V battery.  Both Sicks were powered from it, as was the AREF (using a zener 4V7 to cut it down).  The signal from the digitally configured Sick used a simple divider to reduce 12V to around 5V and the analogue output was just as nature intended because it is low anyway (even though the specs say max 6V, I've never seen it above 3V and only then when it was 'blinded' by perpendicular light I think).  One thing though, the Uno was powered by USB which was still being used to give feedback to the PC.

Pages: [1] 2 3