adc ldr the hard way

T

terrapinlogo

Member
I found a cybot hidden in a box the other day and have pulled it out in hope of converting it to picaxe control. I am trying to use the original light io board to read the ldr's. The board charges a capacitor via the ldr, the micro then measures how long it takes to charge. I have hooked it all up and am currently debuging the code but i seem to be just getting random values.
Schematic

Code: 
main:

low c.2
pause 100
w0=0
let dirsC = %00000000
time:
pauseus 1
w0=w0+1
if pinc.2 = 1 then value
goto time
value:
debug
pause 1000
goto main
 
C

Chavaquiah

Senior Member
I think the Picaxe takes too long to execute each instruction, so you can't get meaningful results with a simple loop. Perhaps you should look instead at using PULSIN:

PULSIN C.2, 0, w0
 
M

MFB

Senior Member
"I wouldn't learn as much then, I already know how to use ReadADC."

What an interesting philosophy! I'm now off to learn glass blowing in order to make sand driven egg timer, because I already know how to generate a delay using the PICAXE.
 
C

Chavaquiah

Senior Member
Are you by any chance using a X2 Picaxe? If so, you could use the internal timer.

Otherwise... how is the capacitor beeing charged? Is it under control of the Picaxe?
 
T

terrapinlogo

Member
Yes i am using a 20x2, but i don't see the timer command anywhere in the manuals. Expand please. The capacitor is connected to ground and to 5v through the ldr. The picaxe is connected to the positive side of the capacitor via a 300 ohm resistor and the capacitor is discharged by pulling c.1 low.
 
T

terrapinlogo

Member
MFB said:
"I wouldn't learn as much then, I already know how to use ReadADC."

What an interesting philosophy! I'm now off to learn glass blowing in order to make sand driven egg timer, because I already know how to generate a delay using the PICAXE.
Click to expand...
I have just decided that I am going to make it work without modifying the actual boards, just by replacing the four processor boards. That is just my excuse because normally i would just use adc.
 
hippy

hippy

Ex-Staff (retired)
Hacking Cybot was what got me into robotics but more importantly into PICAXE.

For using the I/O board I'd use READADC as BeanieBots suggests. Apply 0V and +5V, take the LDR outputs from pins 4 and 5 of the processor socket to ADC inputs with pull-downs to 0V. The 330R's inline should not affect the results nor should leaving C10 and C11 in place. That's then a traditional potential divider with a few extraneous components. If C10 and C11 do affect things you can always unsolder them.

terrapinlogo said:
BeanieBots: Ii wouldn't learn as much then, I already know how to use ReadADC.
Click to expand...
But what will you learn by trying to do it some other way ... ?

1) That it's hard to impossible with a PICAXE
2) That it's time consuming effort
3) That READADC is a far better way
4) That READADC is far easier
5) That you end up having to use READADC anyway
6) That you wasted a lot of time and effort coming to that conclusion

I don't think anyone is against going through the process of trying alternatives to gain understanding and experience but, like walking 600 miles instead of taking a train, it may be better to do it as a paper and mental exercise than actually attempting it.

PICAXE is not really suited to doing 'RCTIME', timing the charging or discharging of a capacitor, because that's not a necessity with READADC available.

It may be possible but you will have to jump through a lot of hoops and may get poorer results than using READADC. What are the values C10 and C11 ?
 
B

BeanieBots

Moderator
terrapinlogo said:
BeanieBots: Ii wouldn't learn as much then, I already know how to use ReadADC.
Click to expand...
I'm sure that's a noble reason but remember that RCTIME is a "botch" to get around not having ReadADC used by another well known PIC based micro:p

By all means learn from the excersise, but I'm quite sure you will (if not already) learn that ReadADC is much better.
 
W

westaust55

Moderator
An untested thought if you absolutely want to avoid using the READADC command.

The portC pins as inputs as ST (ST = Schmitt Trigger)
Thus will not register as an input until the voltage reaches 0.8 x Vdd
So it the suppy (Vdd) = 5.0 Volts then the input would remain low until the voltage reaches 4.0 volts.

How you then acheve the timing is another issue whether using pause, pauseus, or other
 
hippy

hippy

Ex-Staff (retired)
For my efforts with Cybot I took the simplest approach; purchased the chassis and the motor drivers, interfaced the PICAXE directly to the motor driver -

PICAXE -> Motor Driver

That worked but any LDR and other sensors had to connect to the PICAXE board.

The Light I/O Board connects to the Motor Driver with drive lines passed through so it makes sense to change to -

PICAXE -> Light I/O Board -> Motor Driver

That means it's easy to connect LED, LDR, piezo and line follower and using their pre-fitted connectors. It still means having to control four motor drive lines and interfacing to some five other I/O lines.

A better solution may be to include the Light Processor board which handles motors and I/O and interface the PICAXE to that. The beauty of this is that's an I2C slave device so all the PICAXE has to do is issue appropriate I2C read and write commands to control the motors and deal with I/O signals.

PICAXE ---[I2C]--> Light Processor -> Light I/O -> Motor Driver

As to what those I2C commands are and exactly what is needed to make it work I have only a few details but assuming it can be done it would be a quick way to get PICAXE control without having to worry about any complicated hardware interfacing.

The downside is that you will be limited to what the Light Processor provides for and may not have such fine control over motor speeds as an X2 wired directly to the Light I/O board / Motor Driver would have.

I'd been thinking about taking my Cybots out of their boxes and having another play now we have X2's and HPWM and this thought of using I2C also appeals. The sonar is also a two part setup ( controller and I/O board ) and also I2C so it seems a PICAXE could use that with minimal effort ( beyond making I2C work ).

As with cats, and many ways to skin one, what individuals want will vary. Some buy a car, some build a kit car and recyle parts from others while some may build everything from scratch, nuts and bolts through engine to chassis. For some, tweaking the carbs is more fun or rewarding than going for a drive.
 
T

terrapinlogo

Member
Defeat. ADC it is. Now, the LDR has a range of roughly 70R next to a bulb all the way to 2M when covered with my hand. Me thinks 500k pull down will do the trick. Any one got a formula or something that can tell me otherwise??
 
W

westaust55

Moderator
terrapinlogo said:
Defeat. ADC it is. Now, the LDR has a range of roughly 70R next to a bulb all the way to 2M when covered with my hand. Me thinks 500k pull down will do the trick. Any one got a formula or something that can tell me otherwise??
Click to expand...
It is a simple case of performing some resistor/potential divider calcs.
Vout = Vsupply * (LDR ohms) / (LDR ohms + Rseries)

Use that to test various series resistances and for the min and max LDR resiatance values.

You need a value for the series resistor that is
(a) very high relative to the LDR low/bright resistance
(b) very low relative to the LDR high/dark resistance.

From the LDR values you state,
a 12 kOhm resistor on the high side would be the optimal value.

a 12 kohm resistor willl use ~98.8% of the ADC range
whereas
a 500 kOhm will reduce the used range to around 79%
 
J

Jaguarjoe

Senior Member
Be careful with high resistance voltage dividers connected to low resistance ADC's. The input resistance of the PIC's ADC is only 25k ohms. For acceptable (but not ideal) results the Thevenin equivalent resistance of the voltage divider should be no more than 2k5 ohms.
 
T

terrapinlogo

Member
It is going on the bench at the moment.

Code: 
let adcsetup = %0000001100000000

main:

readadc 9,b1
readadc 8,b2
debug
goto main
I have just put 12k ohm resistors between the output pins on the board and ground and I seem to be getting almost the full range. It goes right down to zero and almost to 255 in bright light. One of the sensors cuts out occasionally so I think it may have a damaged cable or something. I will look at it closer and see what I find.

Next task sonar. That could be a challenge. If any one has any ideas please post them.
 
T

terrapinlogo

Member
terrapinlogo said:
One of the sensors cuts out occasionally so I think it may have a damaged cable or something. I will look at it closer and see what I find.
Click to expand...
Just had a look at it and one of the connectors in the plug was opened out slightly. A quick squeeze with some needle nose pliers fixed it.
 
W

westaust55

Moderator
terrapinlogo said:
Next task sonar. That could be a challenge. If any one has any ideas please post them.
Click to expand...
You need to
(a) provide some details about the sonar module you are using (all our crystal balls have had to go back under warranty :eek: )

(b) show how the PICAXE conencts to the wiring diagram you have posted.
Which PICAXE pin goes to which terminal on the conenctor.

A proper schematic as opposed to a wiring diagram is far easier for folks to read/understand.
 
hippy

hippy

Ex-Staff (retired)
This is a schematic of the Sonar I/O board -

http://www.lpilsley.co.uk/cybot/sonario.htm

Here's a schematic of the Sonar Processor Board which connects to it -

http://www.lpilsley.co.uk/cybot/processor2_board.htm

Another circuit, some explanation and waveforms here -

http://www.cybench.co.uk/cybot/sonar.php

As mentioned earlier, I'd likely consider interfacing via I2C to the Processor Board rather than directly to the I/O Board.

When I had considered a direct to I/O board interface I was going to start with a single PULSOUT and see what happened, then move on to HSEROUT to generate up to five pulses. With a diode it would be possible to AND a PULSOUT with PWMOUT for a specific length burst. HPWM could perhaps be used as a diffential drive for the TX which would help range.

Added : Having dragged a Cybot out of its slumber, I2C seems the most obvious way to go. The three motor / LDR boards sit on the chassis, the two Sonar boards sit on top of those, and it's an I2C bus nearest the front. A PICAXE board just needs a five pin molex at one end and it can get power and talk to both boards.

I'd never really thought about the 'system design' of Cybot before but that is quite clever. Eight years too late; it all makes sense now!
 
Last edited:
T

terrapinlogo

Member
I have got a cybot up to issue 36, but i don't have a I2C protocol decoder. From what i can gather from the page you linked to Hippy, if i remove the light processor board and then connect to the sonar processor board via I2C. In theory i should be able to read address 0x7F and get 0011xxxx back where the x's are the switch settings. The next step is to see if i can get sonar values out of it.
 
hippy

hippy

Ex-Staff (retired)
Having re-read the information it seems I2C control of the Motors and Light I/O may not be possible as the Light Processor is a master not a slave. The sonar is a slave so remomoving the Light Processor and reading device $7F should get something from the Sonar Processor. That will likely be ...

I2cSlave $FE, I2CSLOW, I2CBYTE
I2cRead (b0)

Found some earlier work I did with direct sonar interfacing ...

http://www.picaxeforum.co.uk/showthread.php?t=4999
 
T

terrapinlogo

Member
Yes that was the same conclusion that i arrived at as well, but i already have the light i/o board working (not in the intended way, but working none the less) and the motors should just be pulling pins high or low (I might add PWM speed control as well at a later date)
 
Last edited:
T

terrapinlogo

Member
I2cSlave $FE, I2CSLOW, I2CBYTE
I2cRead (b0)

I thought hi2csetup and hi2cin where for X2 parts instead of i2cslave and i2cread?
Is there any difference in this case?
 
hippy

hippy

Ex-Staff (retired)
Sorry, for the X2 it's ...

HI2cSetup I2CMASTER, $FE, I2CSLOW, I2CBYTE
HI2cIn ( b0 )

No difference in functionality.

It's a shame the Cybot community petered out, only early boards were reverse engineered and most hacking was using chassis and motors and interfacing to the motor driver board ( not the best design apparently ) or replacing that. No one really got to investigating the higher level architecture.

There are additional boards which get added which may override the Light Processor to allow its use as a slave or perhaps the Light Processor pulls data from those boards.

I still think it's a good beginners base for all its fault especially as '£400 of parts' can sometimes be had for around £10 though in an unknown state and potentially a lot of work to make it useful.

For an altogether more PICAXE friendly robot there's the Rev-Ed BOT120 PICAXE-20X2 Microbot.
 
Last edited:
T

terrapinlogo

Member
I just hooked it all up and tested it and got no response.

Code: 
hi2csetup i2cmaster, $7f, i2cslow, i2cbyte
main:
hi2cin 0, (b0)
debug
pause 1000
goto main
I even tried this to see if I could get it to run at 25khz I2C. Closer to the 29.8khz stated on the site. Not sure if my code was outputing 25khz I2C but it didn't work either.

Code: 
setfreq m4
hi2csetup i2cmaster, $7f, i2cslow_16, i2cbyte
main:
hi2cin 0, (b0)
debug
pause 1000
goto main
 
hippy

hippy

Ex-Staff (retired)
Change the $7F to $FE - The $7F is a 7-bit device address and the PICAXE uses 8-bit device addressing so it needs shifting left by one bit.

Also, don't specify a memory address in the HI2CIN command, just use "HI2cIn(b0)".

You may also need to add 4K7 pull-ups to +V on the I2C SDA and SCL lines.
 
hippy

hippy

Ex-Staff (retired)
Some interesting results with direct driving of the Sonar I/O board, really a follow on from the previous work at the earlier link, using a 20X2 and with a Logic Analyser to see what's happening.

There are so many possibilities that I really think you'll need a scope or an analyser to see what's happening, decide what suits you best and base your code around that decision.

A single 12us pulse worked amazingly well for what it is but with limited range. With transmitters put across two pins, both set low, pulse one then the other worked even better, and sending five pulses via HSEROUT at 80,000 baud works for better range.

The incoming stream is clear enough and 40kHz bursts can be seen moving around as obstacles are moved but overall it's a bit messy, inconsistent and not easy to decide how best to deal with it.

Obstacle detection looks easy enough. Connect the incoming to a HINTx pin and HINTSETUP, trigger, pause, clear hintXflag, pause some more, check the hintXflag.

Range determination looks more complicated, but the same hardware could probably work; count time until interrupt occurs.

As for reading the Processor Board via I2C ... no joy at all, not even with bit-banging. Note the uC2 circuit diagram is wrong, SDA/SCL go to different micro pins than shown but swapping SDA/SCL doesn't help.
 

Attachments

hippy

hippy

Ex-Staff (retired)
Direct drive of sonar I/O board looked possible but I haven't been able to get it to perform at all well. One of the complaints on Cybot was that the sensors are too wide-angled and that seems to be part of the problem I'm having.

Input is a stream of 40kHz bursts which isn't easy to process except by detecting edges with HINTx pins and when doing so it doesn't seem that consistent. An RC with fast diode discharge to zero, slow rise via R to output stream might help, give an alternative approach. I don't really have the time to twiddle or experiment in depth.

It has however given me an appreciation of the value for money the SRF05 is if you are costing time even at basic wage.

@ terrapinlogo : If you do have any success with the sonar, direct or via I2C, do let us all know. I'm sure it can be done with the right commitment. Will be interesting to see what you do with your Cybot anyway.
 
T

terrapinlogo

Member
Yes I will post again if I get anything but today is the last day of the holidays so it could be a while before I get some spare time with school etc. Considering the only test equipment I have at the moment is a multimeter I will most likely go and get a SRF05 or similar.
 
C

cactusface

Senior Member
Cybots...

terrapinlogo said:
I found a cybot hidden in a box the other day and have pulled it out in hope of converting it to picaxe control. I am trying to use the original light io board to read the ldr's. The board charges a capacitor via the ldr, the micro then measures how long it takes to charge. I have hooked it all up and am currently debuging the code but i seem to be just getting random values.

I too have a couple of Cybot's lurking in the cupboard. And have had thoughts of converting them to PicAxe control, but I think I would just use the basic hardware and build a Picaxe board to run it, or better still just design you own! That's a weird way of using a LDR to charge a cap for timing?? or have I missed something... Can't think where it is now but there is a website with all the Cybot CCT's etc. that could help.

Cybot was good, but they never gave you the info you really needed, it was very basic on the info side.
Regards
Mel.
Click to expand...
 
hippy

hippy

Ex-Staff (retired)
cactusface said:
That's a weird way of using a LDR to charge a cap for timing?? or have I missed something...
Click to expand...
It's an alternative and, importantly, cheap way to measure a resistance when the controlling micro does not have ADC on-chip. That may be the micro manufacturer's philosophy in not including ADC on-chip or the circuit designers choosing a micro without to save costs.

The time taken to charge a discharged C so an input pin goes from low to high varies with R so by measuring the time taken you can determine the value of R.

With a fixed R the technique can also be used to determine the value of C.
 
You must log in or register to reply here.
Top