From: jumpnowdev <sc...@ju...> - 2012-10-19 19:15:06
|
I'm getting some bad measurements trying to use all 6 of the Gumstix ADCs at one time. It's a 3.2 kernel using the new madc driver accessible through sysfs. The problem I am seeing is a signal applied to one ADC is affecting the other ADCs. I've gotten the same results with two different COMs (one Earth, one Fire) with two different expansion boards (Summit, Chestnut43) using two different breadboards. Here's the test: A signal applied to one ADC at a time. All other ADCs and AGND are connected to the signal ground. The signal is from a bench power supply. The first and last rows are with all ADCs connected to AGND. 0.5v DC signal root@overo:~/temp# ./polladc -d100 2 3 4 5 6 7 (use ctrl-c to stop) ADC 2 3 4 5 6 7 Read 158: 12 134 129 129 122 14 Read 233: 535 139 149 131 124 17 Read 343: 17 535 134 129 122 17 Read 431: 14 134 540 207 171 17 Read 526: 14 134 141 540 136 9 Read 608: 12 134 134 122 525 12 Read 705: 4 134 146 122 139 540 Read 786: 14 149 134 124 127 21 1.2v DC signal root@overo:~/temp# ./polladc -d100 2 3 4 5 6 7 (use ctrl-c to stop) ADC 2 3 4 5 6 7 Read 76: 12 134 146 124 129 14 Read 205: 1234 149 146 127 134 17 Read 307: 7 1126 122 124 141 12 Read 408: 17 207 1075 630 205 17 Read 477: 19 131 464 1080 290 19 Read 570: 14 127 109 78 1138 17 Read 654: 19 136 131 122 134 1241 Read 688: 19 122 122 127 134 9 I've only ever used one of the ADCs at a time and never noticed this. Maybe someone else could verify this or explain what I'm doing wrong? The program I'm using can be found here https://github.com/scottellis/polladc -- View this message in context: http://gumstix.8.n6.nabble.com/Gumstix-on-board-ADCs-tp4965762.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Steve S. <sa...@gm...> - 2012-10-19 19:24:11
|
On Fri, Oct 19, 2012 at 12:14 PM, jumpnowdev <sc...@ju...> wrote: > I'm getting some bad measurements trying to use all 6 of the Gumstix ADCs at > one time. > It's a 3.2 kernel using the new madc driver accessible through sysfs. I believe that this is an issue that has been discussed on the list earlier. If so, it is related to interactions between the musb part of the 4030 and the MADC part of the 4030. These interactions are only on channels 3 through 6, and if you look at you readings channels 2 and 7 look reasonable. You might try repeating the test with something plugged into the musb port. I suspect you will get the desired results then. There is a patch submitted to the list that google can probably find. Steve > The problem I am seeing is a signal applied to one ADC is affecting the > other ADCs. > > I've gotten the same results with two different COMs (one Earth, one Fire) > with two > different expansion boards (Summit, Chestnut43) using two different > breadboards. > > Here's the test: > > A signal applied to one ADC at a time. > All other ADCs and AGND are connected to the signal ground. > The signal is from a bench power supply. > > The first and last rows are with all ADCs connected to AGND. > > 0.5v DC signal > > root@overo:~/temp# ./polladc -d100 2 3 4 5 6 7 > > (use ctrl-c to stop) > > ADC 2 3 4 5 6 7 > Read 158: 12 134 129 129 122 14 > Read 233: 535 139 149 131 124 17 > Read 343: 17 535 134 129 122 17 > Read 431: 14 134 540 207 171 17 > Read 526: 14 134 141 540 136 9 > Read 608: 12 134 134 122 525 12 > Read 705: 4 134 146 122 139 540 > Read 786: 14 149 134 124 127 21 > > > 1.2v DC signal > > root@overo:~/temp# ./polladc -d100 2 3 4 5 6 7 > > (use ctrl-c to stop) > > ADC 2 3 4 5 6 7 > Read 76: 12 134 146 124 129 14 > Read 205: 1234 149 146 127 134 17 > Read 307: 7 1126 122 124 141 12 > Read 408: 17 207 1075 630 205 17 > Read 477: 19 131 464 1080 290 19 > Read 570: 14 127 109 78 1138 17 > Read 654: 19 136 131 122 134 1241 > Read 688: 19 122 122 127 134 9 > > > I've only ever used one of the ADCs at a time and never noticed this. > > Maybe someone else could verify this or explain what I'm doing wrong? > > The program I'm using can be found here > https://github.com/scottellis/polladc > > > > > -- > View this message in context: http://gumstix.8.n6.nabble.com/Gumstix-on-board-ADCs-tp4965762.html > Sent from the Gumstix mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Keane, B. (STRX) <ben...@ka...> - 2012-10-21 22:39:07
|
Hi Jumpnowdev, > -----Original Message----- > From: Steve Sakoman [mailto:sa...@gm...] > Sent: Saturday, 20 October 2012 5:24 AM > To: General mailing list for gumstix users. > Subject: Re: [Gumstix-users] Gumstix on-board ADCs > > On Fri, Oct 19, 2012 at 12:14 PM, jumpnowdev <sc...@ju...> > wrote: > > I'm getting some bad measurements trying to use all 6 of the Gumstix > > ADCs at one time. > > It's a 3.2 kernel using the new madc driver accessible through sysfs. > > I believe that this is an issue that has been discussed on the list earlier. If so, > it is related to interactions between the musb part of the 4030 and the MADC > part of the 4030. > > These interactions are only on channels 3 through 6, and if you look at you > readings channels 2 and 7 look reasonable. > > You might try repeating the test with something plugged into the musb port. > I suspect you will get the desired results then. > > There is a patch submitted to the list that google can probably find. I submitted the patch to the mailing list. Here is a link to that conversation: http://permalink.gmane.org/gmane.linux.distributions.gumstix.general/64819 HTH, Ben PROPRIETARY: This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. |
From: jumpnowdev <sc...@ju...> - 2012-10-23 12:32:03
|
Plugging the MUSB port into a PC I lose channels 3-6 completely. Unplugging the MUSB I get data back, though still bad. Here is with all ADCs connected to 1.8v ADC 2 3 4 5 6 7 Read 1388: 1849 1757 1708 1759 1727 1847 no MUSB Read 1479: 1901 17 21 19 12 1889 MUSB Read 1519: 1854 1769 1700 1759 1720 1847 no MUSB I get the same results with the MUSB connected on boot or attached when the system is running. Ben, I tried your patch and it did change the behavior. With your patch if the MUSB is connected on boot I get readings on ADC[3-6] again, but with the same cross-talk problem. The results stay the same, ADC[2,7] good, ADC[3-6] flaky if I disconnect the MUSB. If I then reconnect the MUSB while running, I lose channels ADC[3-6] again the same as without your patch. MUSB connected on boot. ADC 2 3 4 5 6 7 Read 523: 14 119 122 114 122 4 MUSB, ADC[2-7] -> AGND Read 760: 1527 1478 1483 1478 1444 1534 MUSB, ADC[2-7] -> 1.5v Read 970: 1534 1480 1483 1478 1449 1534 NO MUSB, ADC[2-7] -> 1.5v Read 1127: 1544 7 12 9 7 1546 MUSB, ADC[2-7] -> 1.5v Another observation, the signal voltage makes a difference. This is without Ben's patch. ADC[5] connected to signal, all other ADCs grounded, no MUSB First line, signal at 0v Second, 0.5v Third, 1.0v Fourth, 1.5v Fifth, 1.8v Sixth, 2.0v ADC 2 3 4 5 6 7 Read 364: 17 131 134 127 129 9 Read 445: 19 129 153 535 149 17 Read 519: 12 127 344 899 227 12 Read 579: 4 36 425 1300 102 4 Read 716: 9 19 29 1534 17 4 Read 798: 9 19 17 1769 12 7 The cross-talk stuff seems to stop between 1.5v and 1.8v, but ADC[5] still doesn't report the correct voltage. These tests were with a third system, FireStorm COM, Tobi expansion board. -- View this message in context: http://gumstix.8.n6.nabble.com/Gumstix-on-board-ADCs-tp4965762p4965782.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Keane, B. (STRX) <ben...@ka...> - 2012-10-23 21:48:27
|
Hi Scott, I had the cross-talk problem as well in my testing. I added 100k pull-downs to all ADCIN lines on our custom expansion board which I believe was the solution. Our custom expansion board also has a hub on it - so the MUSB is always connected and therefore I haven't seen your new behaviour sorry. I would believe someone on re-connecting the registers I set in the patch are being un-set - or the power to that part of the tps65950 is being turned off again? Are you able to add printk's to different parts to print out different registers to find if they are being changed? Also - I don't know what you mean by flaky - but I experience ADC conversion timeouts.. I changed the timeout to 10 instead of 5: In drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c ret = twl4030_madc_wait_conversion_ready(twl4030_madc, 10, method->ctrl); //default timeout was 5ms, but changed to 10 I still experience a timeout every now and then - but it wasn't all the time like before. I also turned on hardware averaging (which in the datasheet is a 4 sample average): @@ -609,6 +611,7 @@ int twl4030_get_madc_conversion(int channel_no) req.method = TWL4030_MADC_SW2; req.active = 0; req.func_cb = NULL; + req.do_avg = 1; //Added averaging ret = twl4030_madc_conversion(&req); if (ret < 0) return ret; HTH, Ben > -----Original Message----- > From: jumpnowdev [mailto:sc...@ju...] > Sent: Tuesday, 23 October 2012 10:32 PM > To: gum...@li... > Subject: Re: [Gumstix-users] Gumstix on-board ADCs > > Plugging the MUSB port into a PC I lose channels 3-6 completely. Unplugging > the MUSB I get data back, though still bad. > > Here is with all ADCs connected to 1.8v > > > ADC 2 3 4 5 6 7 > Read 1388: 1849 1757 1708 1759 1727 1847 no MUSB > Read 1479: 1901 17 21 19 12 1889 MUSB > Read 1519: 1854 1769 1700 1759 1720 1847 no MUSB > > I get the same results with the MUSB connected on boot or attached when > the system is running. > > > > Ben, I tried your patch and it did change the behavior. With your patch if > the > MUSB is connected on boot I get readings on ADC[3-6] again, but with the > same cross-talk problem. > > The results stay the same, ADC[2,7] good, ADC[3-6] flaky if I disconnect the > MUSB. > > If I then reconnect the MUSB while running, I lose channels ADC[3-6] again > the > same as without your patch. > > MUSB connected on boot. > > ADC 2 3 4 5 6 7 > Read 523: 14 119 122 114 122 4 MUSB, ADC[2-7] -> > AGND > Read 760: 1527 1478 1483 1478 1444 1534 MUSB, ADC[2-7] -> > 1.5v > Read 970: 1534 1480 1483 1478 1449 1534 NO MUSB, ADC[2-7] > -> 1.5v > Read 1127: 1544 7 12 9 7 1546 MUSB, ADC[2-7] -> > 1.5v > > > Another observation, the signal voltage makes a difference. > > This is without Ben's patch. > > ADC[5] connected to signal, all other ADCs grounded, no MUSB > > First line, signal at 0v > Second, 0.5v > Third, 1.0v > Fourth, 1.5v > Fifth, 1.8v > Sixth, 2.0v > > ADC 2 3 4 5 6 7 > Read 364: 17 131 134 127 129 9 > Read 445: 19 129 153 535 149 17 > Read 519: 12 127 344 899 227 12 > Read 579: 4 36 425 1300 102 4 > Read 716: 9 19 29 1534 17 4 > Read 798: 9 19 17 1769 12 7 > > The cross-talk stuff seems to stop between 1.5v and 1.8v, but ADC[5] > still doesn't report the correct voltage. > > These tests were with a third system, FireStorm COM, Tobi expansion board. > > > > > -- > View this message in context: http://gumstix.8.n6.nabble.com/Gumstix-on- > board-ADCs-tp4965762p4965782.html > Sent from the Gumstix mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > __________________________________________________________ > ____________ > CAUTION: This message was sent via the Public Internet and its authenticity > cannot be guaranteed. PROPRIETARY: This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. |