DE-ACCM3D accelerometer & Junebug - A/D question

I got my **broken link removed** and have it wired up to the Junebug. Junebug is reading AN1, AN2 and AN3 and spitting out numbers to the UART tool. I have the 18F1320's AD in 8-bit mode, dropping the bottom 2 bits and am getting numbers in the range of approximately 68 to 103 decimal on each axis (1g gravity - I'm just tilting it). The actual voltages output by the accelerometer would be approximately 1.33V to 1.99V.

Now my newb question: I have the 18F1320 set to use the internal AVDD (5V) for a reference. If I set it for External VREF+ and feed RA3 with 3.3V from the regulator on the accelerometer, will I get a wider range of values in ADRESH? Or in other words, will I get better sensitivity?

Should I switch to 10-bit and rewrite my software?

This photo is slightly out of date. Had to add a power supply to the breadboard as the Junebug/PICkit2 can't supply VDD and do UART tool at the same time.

I got my DE-ACCM3D accelerometer and have it wired up to the Junebug. Junebug is reading AN1, AN2 and AN3 and spitting out numbers to the UART tool.

I have the 18F1320's AD in 8-bit mode, dropping the bottom 2 bits and am getting
numbers in the range of approximately 68 to 103 decimal on each axis (1g gravity - I'm just tilting it).

The actual voltages output by the accelerometer would be approximately 1.33V to 1.99V.

Click to expand...

Hi futz,
Some calculations that may help:

5Vref, 10bit
Val1= [1.33/5] * 1023 = 272
Val2= [1.99/5] *1023 = 407

5Vref, 8bit
Val1a= [1.33/5]*255= 67
Val2a=[1.99/5] * 255 =101

2.5Vref, 10bit
Val1=[1.33/2.5]*1023 = 544
Val2=[1.99/2.5]*1023 = 814

2.5Vref, 8bit
Val1a=[1.33/2.5]*255 = 135
Val2a=[1.99/2.5]*255 = 202

Ideally to increase the resolution to cover the span and offset of the accelerometer you need a OPA with Offset.

Hope this helps.

hi futz,

This is a simple instrumentation amp with offset, I designed for use with a altimeter.
The principle is the same for accelerometer, it would require a lower setting for the Offset voltage and a tweak to the Gain.

The Acc 1.33V to 1.99V would be offset to 0v thru +5V, giving an ADC value of 255 or 1023 max, depending upon the justification of the ADC value.

Do you follow OK.?

ericgibbs said:

Hi futz,
Some calculations that may help:

Ideally to increase the resolution to cover the span and offset of the accelerometer you need a OPA with Offset.

Hope this helps.

Click to expand...

It does. Thank you for the comments and calculations.

I did some reading of the datasheet too, and calculated that at -3g the output voltage will be .66V and at 3g it will be 2.66V (it's a 3g accelerometer). It's already op amp buffered - not just a bare accelerometer chip. It looks to me like just doing a 3.3V ref voltage will give me the kind of results I want without extra circuitry.

So at 3.3V VREF+ I should see approximately:
-3g = .66V = 51
-1g = 1.33V = 103
0g = 1.66V = 128
1g = 1.99V = 154
3g = 2.66V = 206


I'll try it today and see.

The DE-ACCM3D datasheet.

Hey Blueroom Bill! If you're reading this thread, why does AN4 have a pullup?

I moved my Z axis to AN4 (so I could feed AN3 with a 3.3V reference) and it won't work. I'm pretty sure it's because of that pullup. The accelerometer is fine and the cable is fine. I moved wires around to test all that.

Anyway, giving the AD a 3.3V reference worked as I predicted. Full range (-3g to +3g) gives me a ADRESH value swing from approx 51 to 206. Quite useable.

AN4 has a pullup for 1wire stuff, also on older PICs including the 18F1320 RA4 is an open collector output.

I did design the Junebug with +VREF as one of the experiments (using VR2) and VR1.

You could move the Z axis to RB3 (yes it's analog) or RB4 (the RX pin). Use a software UART on TX.

Just my 2c

I always enjoy your Junebug articles and photos futz.

blueroomelectronics said:

You could move the Z axis to RB3 (yes it's analog) or RB4 (the RX pin). Use a software UART on TX.

Click to expand...

I don't really need my Z axis right now anyway. I just unplugged it.

What I'm moving gradually toward is a balancing robot, so I'll really only need one axis. I know everyone says you can't do it without a gyro because the oscillations feed back and the thing falls down, but I'm going to try anyway. I can't believe you can't write some smart software that compensates and damps things.

Any robot I build will be very unlikely to be carrying my Junebug anyway. I'd probably either build a pic-proto type board for it or just use a solderless breadboard for easy changes.

And I think that proper accelerometer location on the bot could go a long way towards making it more stable. I figure that if I locate it at the "CG", or midpoint, the accel won't feel the g-forces as much and won't oscillate so hard. Watch me be dead wrong.

And if I fail I'll learn something anyway, and I'll have the chassis all ready to add a gyro onto.

Balancing robots are cool.
http://www.geology.smu.edu/~dpa-www/robo/nbot/

I've seen one using a Sharp IR sensor to balance, can't recall the link though. Would be a fun mod for the Mongoose.

blueroomelectronics said:

Balancing robots are cool.
http://www.geology.smu.edu/~dpa-www/robo/nbot/

I've seen one using a Sharp IR sensor to balance, can't recall the link though. Would be a fun mod for the Mongoose.

Click to expand...

They are cool. Guys are finding them too easy now, so the new thing is to build a unicycle (one wheel) balancer.

I've seen quite a few that use IR sensors, and a few that use ultrasonic (sonar). They're not as smooth and nice as gyro/accel types though. Even simpler are the ones that use a pot and floor sensor whisker, but they need smooth floors to run on.

In 2006 Scientific American had an interesting article on ball bots. They sort of looked like giant roll on deorderants.

EDIT: Found the article online.
https://www.electro-tech-online.com/custompdfs/2008/05/Ballbots.pdf

3v0 said:

In 2006 Scientific American had an interesting article on ball bots. They sort of looked like giant roll on deorderants.

EDIT: Found the article online.
https://www.electro-tech-online.com/custompdfs/2008/05/Ballbots-1.pdf

Click to expand...

The unicycle bots I've seen used one wheel that balanced in one axis by the usual rolling back and forth method. The other axis was balanced by a rotating pair of weights or a weighted wheel, like a tightrope walker's arms or the balance stick they use. It just gets rotated the right way to correct the imbalance.

I guess you'd need another set of horizontal "arms" to steer with.

Here are two:
https://www.youtube.com/watch?v=OnRV-ggJmQ4
https://www.youtube.com/watch?v=IlMMWFwHti4

Here's the BallBot. Pretty cool machine:
https://www.youtube.com/watch?v=5le0tQBrGJU&feature=related

If anyone is interested, photos, movies and source code have been published.

Excellent. Are you going to take it further and build a balancing bot?

Mike.
P.S. Are you going to get that FAT16 code written?

Pommie said:

Excellent. Are you going to take it further and build a balancing bot?

Click to expand...

Yes.

P.S. Are you going to get that FAT16 code written?

Click to expand...

I haven't even got RAW mode working yet. I'm right there - so close. It almost works. But another shiny thing distracted me and the SD is on back burner now.

I'll eventually get back to it...

Pommie said:

Excellent. Are you going to take it further and build a balancing bot?

Click to expand...

Hehehe

A few months ago I caught a guy on his way to the street to put his ancient Meccano set in the garbage. Saved it and now it's my balancer chassis.