pyb.ADCAll() side effect

The official pyboard running MicroPython.
This is the reference design and main target board for MicroPython.
You can buy one at the store.
Target audience: Users with a pyboard.
User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

pyb.ADCAll() side effect

Post by pythoncoder » Tue Dec 08, 2015 9:15 am

Bug or a feature? In the following example pin Y11 controls an LED via a MOSFET. If the pin goes low the LED turns on. If it goes high or high-z the LED goes off.

Code: Select all

>>> import pyb
>>> al = pyb.Pin('Y11', mode = pyb.Pin.OUT_PP)
>>> al.low() # LED goes on
>>> adc = pyb.ADCAll(12) # Now it goes off (??)
Peter Hinch
Index to my micropython libraries.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: pyb.ADCAll() side effect

Post by Roberthh » Tue Dec 08, 2015 9:53 am

It's not too surpising the enabling the ADC switches the port to High-Z (assuming you wanted to write pyb.ADC("Y11")). And what that does to your external circuitry, depends on how this is set up.
Or do I miss the point?
Update: Found pyb.ADCAll() in the examples of the documentation, which is sometimes a little bit sparse. I assume it enables all ADC inputs.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: pyb.ADCAll() side effect

Post by pythoncoder » Tue Dec 08, 2015 11:48 am

Its purpose is to enable me to read battery and reference voltages with

Code: Select all

return adc.read_core_vbat(), adc.read_core_vref()
Since these are internal voltages it surprised me it affected pins, but I'm evidently missing something.
Peter Hinch
Index to my micropython libraries.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: pyb.ADCAll() side effect

Post by Roberthh » Tue Dec 08, 2015 12:13 pm

A documentation of pyb.ADCAll()'s semantics should help. Yes, in theory I could look into the source code to find out, what exactly a certain non-standard-python function is doing, but until now the initial hurdle seemed to hight for the questions I had. I took the try-and-error approach instead.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: pyb.ADCAll() side effect

Post by pythoncoder » Thu Dec 10, 2015 6:59 am

If anyone is following this I've looked at the source and it seems that ADCAll() sets all relevant pins as ADC inputs. This explains the behaviour I'm getting. It seems unfortunate if the only way to read Vbat and Vref has this side effect.
Peter Hinch
Index to my micropython libraries.

Stevo52
Posts: 38
Joined: Sun Feb 03, 2019 10:28 pm

Re: pyb.ADCAll() side effect

Post by Stevo52 » Mon Dec 30, 2019 7:51 am

How lucky am I that two of the best on the forum have already done some work with ADCAll.

My issue is not with the side effect you discuss, because I use external 16/20 bit ADC via I2C, so the switching of pins doesn't impact measurements. I am interested in using this because, like pythoncoder, it seems a very convenient way to get this information in one go and the documentation seems to support this.

My issue is that my code:
# Define the ADC object
adc_core=pyb.ADCAll(12, 0x70002)

def get_cDAT():
# Routine to return actual core battery and ref voltages, plus temp
cor_dat = adc_core.read_core_vbat(), adc_core.read_core_vref(),adc_core.read_core_vbat(), adc_core.read_core_temp()
if cor_dat[0] <= 3.40:
# lowBatt(bat_vdc)
batlow = 1
else: batlow = 0
return cor_dat[0],cor_dat[1], cor_dat[2],batlow

returns:
MicroPython v1.10-418-g8ef236ec5-dirty on 2019-03-26; PYBD_SF2W with STM32F722IEK (also tried a PYBD-SF6-W4F2 - same result)

17:24:00 << This is a check I am running on a 1 minute timer at the same time
0.5077777 Vbat 1.205568 Vref 0.4984092 deg << These are the returned core data from the function above.
17:25:00
0.5048821 Vbat 1.205568 Vref 0.511355 deg
17:26:00
0.511355 Vbat 1.205568 Vref 0.5077777 deg

The PYBD is mounted to a WBUS-DIP28 to allow the battery and I am connected through the FS port and using PuTTY for the REPL and Notepad for editing because I am still deciding what IDE is best suited for the PYBD and the user (me).

A voltmeter directly across the battery gives an increasing voltage so I believe it is charging (currently 4,00 V and rising slowly as it should be).

The documentation says "The ADCAll read_core_vbat(), read_vref() and read_core_vref() methods read the backup battery voltage, reference voltage and the (1.21V nominal) reference voltage using the actual supply as a reference. All results are floating point numbers giving direct voltage values." but the Core_VBat and Core_Temp aren't correct but Core_VRef is OK.

Can you suggest what is wrong here?

Do I have to correct these readings in code or is what being returned incorrect? I am probably missing something but I can't see it..

chuckbook
Posts: 135
Joined: Fri Oct 30, 2015 11:55 pm

Re: pyb.ADCAll() side effect

Post by chuckbook » Mon Dec 30, 2019 8:06 pm

1. Note that core_vbat refers to the RTC backup battery. To read supply voltage use vref.
2. core_temp is stored in cor_dat[3]!
3. On a PYBD will never be bigger than 3.3V (well +/- some error) due to the LDO used for Vdd.

Stevo52
Posts: 38
Joined: Sun Feb 03, 2019 10:28 pm

Re: pyb.ADCAll() side effect

Post by Stevo52 » Mon Dec 30, 2019 10:47 pm

Thanks chuckbook, yes that error in the script (which was an artifact from experimenting) was the problem with reading core_temp and it is now reading fine, but I don't really need that for my project.

The documentation I had read hadn't specifically mention that it was the RTC battery ( I guess MC_Bat is the clue there), so that explains that then and means unfortunately that ADCAll is not the answer for measuring the external system battery. So I will have to take a more traditional approach to that - luckily it is raining today so there will time for coding!

I must admit though that I sometimes get frustrated with the documentation because it misses some important information. RTC is quie important in this application because data being obtained is referenced to other information obtained externally. But where would I connect the RTC backup battery to;- the VBAT as an 'off the board' battery? Or on the WBUS-DIP28 (large circular pad). What type and is a rechargable battery possible?

My next challenge will be identifying where to pick up the system battery - VBAT doesn't seem to appear on one of the WBUS-DIP28 external pins. A VBAT pin does show on the PYBD though Between X1 and X2

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Pyboard D RTC battery

Post by pythoncoder » Tue Dec 31, 2019 5:58 am

The schematics for the WBUS-DIP28 show a battery type MS414GE-FL26E. I believe this is the RTC backup battery with a holder soldered to the pads you identified.
Peter Hinch
Index to my micropython libraries.

Stevo52
Posts: 38
Joined: Sun Feb 03, 2019 10:28 pm

Re: pyb.ADCAll() side effect - PYBD Battery

Post by Stevo52 » Tue Dec 31, 2019 8:24 am

Hi pythoncoder..

I have spent a few hours today sorting out the back up battery on the STM32F722 and the WBUS-DIP28.

What I have found is that the WBUS-DIP28 has provision for two backup batteries:

1. The RTC backup battery - this is described in the documentation as you say, with the circular pad and two other pads near the connector for a tile. The battery recommended - MS414GE-FL26E is 'un-obtainium' in this country apparently , likewise the holder. However I discovered through the documents/schemactics/and poking around with the trusty meter, that the 'VBAT' that is the RTC backup battery doesn't appear on the WBUS DIL connections but it does appear on the STM32F722 - top left hand side Y pins 2 and 3 down from the USR button. Interestingly, if you trace the schematics, VBAT becomes VBAT_EXT for the transition though the WBU-A header (Pin 31), then reverts to VBat on the PYBD. While I couldn't get the right rechargeable battery, I wired in a JST 2PH header socket at the pins on the PYBD and then fitted a CR2032 as a temporary solution (with schottky diode inline) - and voila! I have read_core_vbat() data.

2. The second battery is a rechargeable backup for the whole 'system' - connections for it are just behind the USB-FS connector on the WBUS-DIP28. I have a single cell 3.7V Lipo connected there and it charges fine and maintains the system fully running if I disconnect the USB cable. I haven't done a full discharge run on it yet, but I expect there will be a few hours available in the event that the main solar power system fails (this is happening a bit at the moment with storms and cloud, plus smoke haze from the bush fires causing the solar battery to not get to full charge). This is the battery I want to read the voltage from, using a separate ADC pin, a voltage divider and some code, directly from the 'system' back-up battery.

The combination of the external power supply, system battery backup and RTC back up battery is a bit 'belt and braces', but should reduce the incidences of total system power down that have been occurring. My code already allows to recover from that scenario, but not without loss of live sensor data which upsets the client who is make real-time calculation from the information my app provides. So far reliability was at 92.999% with the early GPY version and is currently at 97.22% with the PYBD prototype (running at 216MHz 24/7 - but without reporting some of the system data requested - such as WiFi RSSI and battery voltages, though I am well on the way to resolving those now).

Note that the MS414GE-FL26E battery has two pins on it, so it is not a flat button cell yet the PCB pads seem to be for a button cell holder. While I can't source a MS414GE-FL26E, I have found some LIR2032 CMOS Battery CMOS Battery, so I am researching those., as well as alternative 4.8mm rechargeable cells.

So some progress for me and a much clearer idea of how the PYBD power system is bolted together which will help me refine the external solar power system.

Thanks for all the assistance that has been contributed so far - these relatively simple things have once again take a lot of research and time to come up with solid solutions.

Post Reply