Pololu Robotics & Electronics
My account Comments or questions? About Pololu Contact Ordering information Distributors

Odd 3pi Analog Behaviour



I seem to have some odd analog behaviour reading the battery voltage or user trim pot on my 3pi. My current setup is;

  • Pololu 3pi 0J6242 (mega328p)
  • AVR Studio 4.18 (inc SP1)
  • WinAVR 20090313
  • Latest Libpololu from website
  • Pololu Programmer PGM03A 0J1345

Right when the unit was shipped to me I could use the preloaded 3pi-demo-program to view the battery volts and twiddle the user pot and see the value changing. Everything checks out fine :smiley:

I then followed the user manual getting started programming the3pi instructions and compiled the simple-test program out of the \libpololu-avr\examples\atmega328p directory. Had a few minor teething problems with drivers and the programmer but these were soon sorted out. Downloaded code and wallah working system (well nearly keep reading).

I then tried to recompile the 3pi-demo-program and download. However when you enter the bat_test function the display is corrupted with rubbish and does not display the battery volts properly. I am seeing the following on the top line of the LCD when entering bat_test “5RpmV” where p is the greek “rho” symbol with ADC6 jumper connected, when removed the value falls to “7mVVV”. I see something similar on the trimpot display. This suggests that the ADC is working, however the translation from ADC to milivolts is being trashed.

I appear to be able do everything other than read from the battery and trimpot correctly. I have compiled and tested the remaining test programs that exercise the Switches, Motors, LEDs, buzzer and line sensors and this is all good. When using the 3pi-demo-program it self all these functions appear to be work also, just not the battery and trimpot.

I’m now kicking myself for not reading the demo program out of the unit before programming, otherwise I would have had the original file and could have diffed the hex files to see what has changed, but alas in my post Christmas excitement I neglected this step. As I mentioned previously the code loaded in the unit worked out of the box so the hardware is a definite goer.

I’ve a feeling that there is something in the libpololu code that is causing me some grief with this particular compiler version and demo program, is anyone else able to replicate this? Or at least give me a clue at to which WinAVR compiler I should drop back to and retest.

Happy New Year!



Hello Matthew,
Are you sure you have the latest version of the Pololu AVR Library? That sounds very much like a bug in print_long() that was fixed in version 091201.

You can read a little more about the issue here.



Hi Paul,

Amazing I searched for quite sometime on the forum before posting and never had a hit with the other thread, but yes this does sound familiar. It appears that I am using libpololu-avr-091106 so I’m downloading the correct lib libpololu-avr-911201 and will see what happens.

Thanks for the helpful tid-bit, with luck I’ll have this licked by the end of 2009 :smiley:




Well that fixed it. Upgraded to the latest version of the library libpololu-avr-911201 and we now have the correct result. So I’m off to see what other trouble I can get into with my 3pi.


PS: Happy New Year 2010 from Australia.