paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] Battery Measurement Problem


From: Gautier Hattenberger
Subject: Re: [Paparazzi-devel] Battery Measurement Problem
Date: Wed, 29 Jan 2014 09:57:08 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

Hi,

The adc_set_injected_sequence function is exactly the same for F1 and F4, and the priorities are the same as before (just set by a macro).
Maybe you can try to use the adc_generic module to figure out which adc channel is actually used for battery monitoring.

Gautier

Le 29/01/2014 09:29, Kadir ÇİMENCİ a écrit :
Hello everyone,
Thanks for the answers, today i had a chance to test all possible problematic cases related with your answers: (all of them is made with two different Lisam v2 boards - stm32f105 to avoid the problems related with hardware) I have directly fed the battery voltage to the V_bat pin.
1) I have been working with a dead Lipo and changed it to a fully charged healthy ones 3s and 4s nothing changed still displaying 9.4 V on gcs
2) Directly fed the board with a DC power supply with constant voltages between 5-15 V , nothing changed, still 9.4V
3) Finally decided it is a problem with software and decided to look at to source code, luckily i have a backup of master release on 22 January(a week ago) and turned back to that snapshot, and i can measure the battery regulary.

I guess it is a problem with updated libopencm3 adc structure. Yesterday Chris had mentioned that everything seems correct with the code, but there may be a specific buggy case for STM32F1 mcu i don't know. Since i measure the same voltage for all different voltage sources, i suspect  i am measuring the same wrong ADc channel. Or there maybe a problem with ADC interrupt priorities and sample times in which V_bat pin is never readed. I suspect these problems may be relevant with these commits which are made after 22 Jan.

https://github.com/paparazzi/paparazzi/commit/daf9408171ad10f2d859f12b57d2dc818566f86c
https://github.com/paparazzi/paparazzi/commit/fd2ae6b95c0b4178fd88f431e9e1daba3b8750d0

Is there someone else who have encountered a problem like this ?

Thank you

Kadir

2014-01-28 David Conger <address@hidden>
I have familiarity with Apogee, I've never had the board tell me the
same value I see on my current limited power supply. It's close but
never the same value. Usually lower reported from the board. LPC2148
autopilots are more accurate and nearly exactly the same as the power
supply.

Just FWIW,
-David

On Tue, Jan 28, 2014 at 10:15 AM, Michal Podhradsky
<address@hidden> wrote:
> I barely remember seeing 9.4V on Lisa board when I powered it with USB only.
> Once it got "real" battery voltage it worked just fine, but I don't know
> what might be the reason.
> M
>
>
> On Tue, Jan 28, 2014 at 6:43 AM, Chris <address@hidden> wrote:
>>
>> Forget about my answer i was wrong the order has changed to a more logical
>> one so the code is looking fine.
>> Chris
>>
>>
>>
>> On 01/28/2014 04:14 PM, Kadir ÇİMENCİ wrote:
>>
>> Hi Chris,
>>
>> Thanks for the answers, as i see from the source code i m only using the
>> ADC14/PC4 on STM32F105 for battery measurement. After your answer i tried to
>> bind this channel as hard coded, at the end of the map like, but no change
>> still reading wrong ADC values from MCU. I guess i am missing something
>> about this ADC mapping..
>>
>> #if USE_AD1
>> #ifdef AD1_1_CHANNEL
>>   adc_channel_map[AD1_1] = AD1_1_CHANNEL;
>> #endif
>> #ifdef AD1_2_CHANNEL
>>   adc_channel_map[AD1_2] = AD1_2_CHANNEL;
>> #endif
>> #ifdef AD1_3_CHANNEL
>>   adc_channel_map[AD1_3] = AD1_3_CHANNEL;
>> #endif
>> #ifdef AD1_4_CHANNEL
>>   adc_channel_map[3] = AD1_4_CHANNEL;  // --> change in here
>> #endif
>>
>>
>> Thanks again..
>>
>> Kadir
>>
>>
>> 2014-01-28 Chris <address@hidden>
>>>
>>> I haven't checked (but if this is the case then i stand corrected, you
>>> are right.
>>> Chris
>>>
>>>
>>> On 01/28/2014 02:31 PM, Gautier Hattenberger wrote:
>>>
>>> Hi Chris,
>>>
>>> Do you have any issue while reading the ADC channels ? Because with the
>>> update version of libopencm3 the initialization order have been changed:
>>> https://github.com/libopencm3/libopencm3/commit/6570f6e
>>>
>>> Gautier
>>>
>>> Le 28/01/2014 13:26, Chris a écrit :
>>>
>>> If you have a stm32 board i think there is some errors in the adc_arch.c
>>> file
>>>
>>>   nb_adc1_channels = NB_ADC1_CHANNELS;
>>> #if USE_AD1
>>> #ifdef AD1_1_CHANNEL
>>>   adc_channel_map[AD1_1] = AD1_1_CHANNEL;
>>> #endif
>>> #ifdef AD1_2_CHANNEL
>>>   adc_channel_map[AD1_2] = AD1_2_CHANNEL;
>>> #endif
>>> #ifdef AD1_3_CHANNEL
>>>   adc_channel_map[AD1_3] = AD1_3_CHANNEL;
>>> #endif
>>> #ifdef AD1_4_CHANNEL
>>>   adc_channel_map[AD1_4] = AD1_4_CHANNEL;
>>> #endif
>>>   // initialize buffer pointers with 0 (not set). Buffer null pointers
>>> will be ignored in interrupt
>>>   // handler, which is important as there are no buffers registered at
>>> the time the ADC trigger
>>>   // interrupt is enabled.
>>>   for (x = 0; x < 4; x++) { adc1_buffers[x] = NULL; }
>>>   adc_init_single(ADC1, nb_adc1_channels, adc_channel_map);
>>> #endif // USE_AD1
>>>
>>> Here is what i think but i may be wrong as my daughter want me to play
>>> with her now and i can't think straight :-)
>>> This will load the adc_channel_map the wrong way.
>>> Suppose we use 2 channels then the first channel (AD1_1) should be loaded
>>> in "adc_channel_map[2]"
>>> and the second channel (AD1_2) in adc_channel_map[3] but here
>>> adc_channel_map[0]=AD1_1
>>> and adc_channel_map[1]= AD1_2.
>>> With this order those channels will not get converted because only
>>> adc_channel_map[2]
>>> and adc_channel_map[3] will be converted which contain the wrong adc
>>> input number.
>>> Chris
>>>
>>> On 01/28/2014 01:39 PM, Kadir ÇİMENCİ wrote:
>>>
>>> Hello everyone
>>> Today i have noticed that there is a problem with battery indicator at
>>> the GCS. I have fed a regulated 5v to the V_batt pin and i see the indicator
>>> shows 9.4 V. It is working regularly at the v5.0.3  release, but when i try
>>> to use master there is a problem with battery state like this. I don't
>>> change the voltage divider resistors (10k and 2.2k) and i have also tried to
>>> define the line
>>>
>>> <define name="VoltageOfAdc(adc)" value ="(0.0045 * adc)"/>
>>> which also the default value for Lisa m v2.0
>>>
>>>  Anyone who have encountered with this problem?
>>>
>>> Thanks
>>>
>>> Kadir
>>>
>>> Board : Lisa mv2.0
>>> Version : master
>>> Frame : Quadrotor
>>>
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>
>>
>>
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>>
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>



--
address@hidden
http://www.ppzuav.com

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


reply via email to

[Prev in Thread] Current Thread [Next in Thread]