ikarso has quit [Quit: Connection closed for inactivity]
vagrantc has quit [Ping timeout: 272 seconds]
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
<ds2>
Can you explain what 'mm' is in this context?
<ds2>
it is a voltage ADC so the correlations are to the voltage.... mm in most context is millimeter and that is a linear measurement which does not directly relate to voltage unless you have some kind of transducer/sensor
<set_>
millimeter
<set_>
Oh.
<set_>
And yeppers, I have a MaxBotix v2 sonar sensor.
<ds2>
look at the datasheet
<ds2>
I suggest doing the following - take 2 1K resistors in series. Connect one end to ground and the other to the 1.8V signal. Connect the middle to an ADC channel. If it is setup as single end, that channel should read 0.9V. If not, figure out the scaling factor to get it to read 0.9V.
<ds2>
Now you have a way of reading the voltage. Consult the datasheet for the sensor and see what voltage correspond to awhat distance. do that match.
<ds2>
do that math I mean
<ds2>
the 1K resistor was choose as a common value that probally won't get too impacted by the input impedence of the ADC
<set_>
Okay.
<ds2>
you can probally get away with even a 2 4.7K resistors, I wouldn't go higher. Lower can work but you will run into drive limit of the 1.8V rail.... 2 470 ohm resistors may work
<set_>
Analog, (Vcc/512) / inch is what it says.
<ds2>
what is Vcc in this case?
<set_>
I am not sure what this means just yet so i will keep testing.
<set_>
I do not know. 3.3v on the BBB?
<ds2>
what are you powering it with?
<set_>
And...I do not know if they mean (/ inch) means by or divided.
<set_>
BBB.
<ds2>
Vcc is usually your power supply...probally 5V or 3.3V... could be 1.8V but...
<set_>
3.3v.
<set_>
I am using another pin for 1.8v from the ADC.
<ds2>
IIRC, the ADCs are max 1.8V
<ds2>
so you will need a divider
<set_>
Oh.
<set_>
Okay.
<ds2>
is the datasheet online?
<set_>
It seems I can connect the ADC directly from what I thought from the beagleboard docs. pages.
<set_>
On the first page, it says Analog. Maybe they mean analog and not ADC.
<ds2>
I believe this is self explanatory given then example: Pin 3-AN- Outputs analog voltage with a scaling factor of (Vcc/512) per inch. A supply of 5V yields ~9.8mV/in. and
<ds2>
3.3V yields ~6.4mV/in. The output is buffered and corresponds to the most recent range data.
<ds2>
for scaling, maybe try a wiring the output to 2 1K resistors in a series. (one end to sensor, other to ground, middle to ADC)
<set_>
Right and a-okay.
<ds2>
since you're powering it at 3.3V, the distance is about 3.2mV per in or 3.2mV per 25.4mm
<set_>
Oh.
<set_>
Okay.
<ds2>
from my experience, there is too much noise to get mm level accuracy
<set_>
Aw. Okay.
<set_>
I will stay with inches then.
<ds2>
maybe cm level if you're lucky
<set_>
I was having trouble with the mm approach in the source code.
<ds2>
it isn't about your choice of units, it is about resolution based on the noise
<set_>
oh.
_av500_ has joined #beagle
av500 has quit [Ping timeout: 260 seconds]
<set_>
When I divide 3.3 by 512, I get 0.0064453125. What does this mean to me?
<set_>
So, 0.0064453125v per inch?
<ds2>
with a Vref of 1.8V, your best resolution is about 500uV so in the best case 3.4mm but that ADC is so noisy, you'll be hard press to get even +/-1 count so maybe 1cm is useable
<ds2>
yes - 0.0064v per inch based on their example
<set_>
Right but...
<ds2>
you should be able to put a DMM on that pin and see that as you move your hand back and forth. just tape the sensor down at one end of a ruler and have your hand move
<set_>
512 is for a 9-bit.
<ds2>
why are you using this sensor?
<set_>
No clue. I am testing to report findings and then moving on to better sensors.
<ds2>
it is probally a 9 bit DAC inside that thing
<set_>
Oh.
<ds2>
or use the digital output
<set_>
So, would I subtract 512 from 4096 or divide by 3 for resolution?
<ds2>
eh?
<set_>
Well.
<ds2>
not getting what you are asking
<set_>
Okay. Let me try to explain...
<set_>
The ADC onboard is 12-bit or 2^12 = 4096.
<set_>
Their DAC is probably, like you mentioned, a 9-bit DAC.
<set_>
512.
<ds2>
treat them as 2 independant things
<set_>
So, in my calculations, I have not accounted...oh.
<set_>
Okay.
<ds2>
so for the sensor, figure out the resolution in volts
<ds2>
do the same on the ADC side
<set_>
But, I cannot just say 4-bit is the answer for the difference right?
<ds2>
completely unrelated
<set_>
Excuse me. 3-bit.
<set_>
Oh.
<set_>
Okay.
<ds2>
you are also scaling to meet electrical limitations
<ds2>
hence convert things to voltages as seen by the respective components then compare
<set_>
Aw.
<set_>
okay. I got why you were saying it now.
<set_>
So, to test hardware and software ideas, I need a reference and not a guess. Got it.
<ds2>
you can increase your effective resolution in 2 ways - (1) buffer and choose a better set of resistors for the scaling. Right now it is roughly 1/2x scaling so your measurements are compressed down to 0-1.6V (throwing out the 1.6-1.8V headroom) (2) oversample
<set_>
So, if one answer is 1.5v and the other answer is 0.5v, then I can assume some type of answer from 0 to 1.
<set_>
Right.
<ds2>
no need to guess...just do the math
<set_>
Okay.
<set_>
I think I can do it.
<ds2>
I personally like the old mathcad where I can write it all out and it'll check my units
<ds2>
I say roughly because ADCs are not ideal inputs, they do weird things so that adds noise hence the buffering
<set_>
Right. From what I have been reading, noise and repeatability are issues.
<ds2>
yes, the real world sucks.
<ds2>
if only we can live at 0K
<set_>
So, one reading may be 10 inches and when I account for the same 10 inches measured, it reports back something different.
<set_>
"I am okay..."
<ds2>
for these analysis, you need to go back to your intended application
<set_>
Got it. And A-Okay.
<ds2>
sonar sensors has been flaky in my experience
<ds2>
LIDAR is more well behaved and the beam is narrower
<set_>
Are 9-bit DACs normal in applications?
<set_>
Aw. Okay.
<ds2>
could be... I donno how sucky is the SONAR itself
<set_>
Sonar is cheap and can make large things, vats of liquids, easy to understand if it is there or not.
<set_>
But, this is the entire reason I have been trying to narrow down results to something more tangible.
<ds2>
Sonar HW is cheap, the amount of engineering to tame the sonar makes that expensive
<set_>
I want to try to get better at using the ADC, 12-bit or 24-bit or whatever, for use with different sensors.
<set_>
and now because of you, I have a starting method.
<ds2>
if you want it as practice, have fun... otherwise, I'd go w/the digital outputs
<set_>
So, something like UART or PWM?
<ds2>
analog is an ugly real world unlike software ;)
<ds2>
yep
<set_>
I know this MaxBotix can handle it.
<set_>
They have examples for it too (sort of).
<set_>
Whelp, time to try UART.
<ds2>
PWM can feed into the tcap stuff and call it a day....uarts are nice but I usually better things to do with them
<set_>
But for brevity and recollecting here, use a set of two resistors in series to handle finding a start to the end result.
<ds2>
the overall performance of the ADC on the 335x has a lot to be desired.
<set_>
I know. It is fast!
<ds2>
yeah, the resistor will do it. it is a bit brute forced
<ds2>
if you want an excerise, figure out how the driver configures and reads the ADC
<ds2>
I did that a long time ago and used it to interface with a mic
<ds2>
there is a lot of things you can tweak that the driver may not expise
<ds2>
expose
<set_>
The ADC driver in the kernel is what you are describing? IIO?
<ds2>
yeah... unless you wrote your own
<set_>
No. I have not.
<set_>
But, I am still working on promoting .c kernel modules to the already running beagleboard.org images.
<set_>
"external"
<ds2>
blah modules...
<set_>
Well, they can be a good start to drivers.
<ds2>
<--- not a fan of modules... monolithic kernels are easiest
<ds2>
preferrably with DT patched out :D
<set_>
so, you would rather compile everything already from the start or again once everything gets loaded?
<ds2>
yep
<ds2>
simple dev cycle
<set_>
Hmm. I like adjusting things but it keeps tainting my kernels.
<set_>
Aw.
<ds2>
makes it easy to bring up boards without pesky bootloaders trying to be too smart
<set_>
No one will ever look at my kernels, so not a big deal. I do not have to worry about people questioning my tainted kernels.
<set_>
Get this...
<set_>
So, I thought I could build the external kernel module as a LKM with a .h file referenced in the .c file.
<set_>
Nope. Whomever sold me that idea was completely wrong.
<ds2>
strictly speaking, you can
<set_>
So, <linux/whatever.h> is needed but not my own .h file that then references a <linux/whatever.h> file too.
<set_>
Oh?
<set_>
I could not get it to compile.
<set_>
my .c called the .h file and reported errors every time. When I changed the .h file to a .c file, it built.
<ds2>
didn't say it was easy... there are macros that get used
<set_>
Oh.
<set_>
I mean, yes. Oh but I needed to #DEFINE a bunch of stuff in my .h file.
<ds2>
but get something going first... use whatever works for you
<set_>
Right. I think this is why my kernel was tainted. The .h file turned .c file was for reference only and not a lkm or external module.
<set_>
Oh well.
<ds2>
no, there are macros that set the copyright/license.. that probally didnt get setup right
<set_>
I understand now. I put 'em in the files. AUTHOR and so on, license...
<set_>
I mean...
<set_>
Should I call the .h as an .o file in the Kbuild and Makefile files?
<set_>
No. Not from what I found.
<set_>
Right?
<set_>
I tried everything. obj-m or obj-y and := and ?= and +=. Notta from what I could configure.
<set_>
The more I read, the more I just wanted to change the .h to a .c.
<set_>
Hmm.
<set_>
I finally got a good pop up of data.
<set_>
ccflags!
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
mvaittin_ has joined #beagle
_av500_ is now known as av500
rob_w has joined #beagle
ikarso has joined #beagle
ft has quit [Quit: leaving]
SJFriedl has quit [Ping timeout: 260 seconds]
Shadyman has quit [Quit: Leaving.]
florian has joined #beagle
buckket has quit [Quit: buckket]
buckket has joined #beagle
rob_w has quit [Remote host closed the connection]
Stat_headcrabbed has joined #beagle
zmatt has quit [Ping timeout: 252 seconds]
mvaittin_ has quit [Ping timeout: 248 seconds]
zmatt has joined #beagle
florian has quit [Quit: Ex-Chat]
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
marcheu has quit [Ping timeout: 252 seconds]
marcheu has joined #beagle
marcheu has quit [Ping timeout: 252 seconds]
marcheu has joined #beagle
Stat_headcrabbed has joined #beagle
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
buzzmarshall has joined #beagle
vagrantc has joined #beagle
ft has joined #beagle
zjason has quit [Read error: Connection reset by peer]