Pico W gives faulty sensor data with latest Micropython version

[opiedopy]

(terminology wording corrected by edit) (2nd edit added # 1 and # 2 to identify different Pico W hardware, both purchased recently from supplier)

On edit: below I apologized for using the word "faulty" in thread title. Correct title would have been "different" instead of "faulty." It was recommended to me that I leave it, since it already has been done.....

I temporarily solved my problem, but any advice is welcome.

I have a Pico W at a remote site that has worked perfectly for 8 months, 24/7.
It was programmed using Thonny last April 2023 with Micropython firmware v1.20.0 (RPI_PICO_W-20230426-v1.20.0.uf2)

Two days ago (Jan 19, 2024) I needed to modify the program. Before downloading the modified code, I decided to upgrade to latest firmware, v1.22.1 (RPI_PICO_W-20240105-v1.22.1.uf2)

I immediately had Thonny error problems of missing modules and had to reload modules such as network and urequests. Socket module also flagged.
(On edit: I later discovered that the module issues and wifi issues were caused by using Pico firmware instead of Pico W firmware.)
After working getting those back, the Pico W was put back into service and two things happened. First, the GPIO27 and 28 outputs were 14 degrees Fahrenheit too high at room temperature on my desk, plus, both sensor outputs were wildly inaccurate when I put them in ice bath and hot water etc. Plus, the Pico W wifi connection was not rock solid anymore and the wifi would jump out randomly.

I am a stubborn soul and spent 10 hours trying to find my error. I even re-soldered some connections. I searched the internet until my fingers were sore.

Two hours ago I got the brainstorm idea that maybe it was not my problem but was Micropython firmware version related. I loaded the older version, v1.20.0, firmware and put in the same program code. The Pico W worked flawlessly and the wifi was solid.

As I said, my problem is solved, but perhaps my issue has broader implications. If I can help anyone with more info, let me know.

Working firmware version:
v1.20.0, RPI_PICO_W-20230426-v1.20.0.uf2
Pico W 1

Non-working firmware version:
v1.22.1, RPI_PICO_W-20240105-v1.22.1.uf2
Pico W 1

my modules:
import machine
import urequests
from machine import Pin,Timer
import network, time
import utime
import math

Thonny lower left info:
Micropython ( Raspberry Pi Pico) /dev/ttyACMO

Thonny Used:
Thonny 4.0,2 , Debian GNU/Linyux (bullseye) (64 bit)
Python 3.10.9 (64 bit)
Tk 8.6.12
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Opie

[robert-hh]

Your observations seems a little bit inconsistent. network is a built-in module of the firmware. You would usually not load it, it's simply there. The urequests module is as well by default included into the firmware. Also, there is no need to import both time and utime. utime is an alias of time and is kept for legacy.
So it may be that the hiccups you see are caused by Thonny. Do you have the same problems when not using Thonny?

[robert-hh]

You can use help("modules") at the REPL prompt to tell, which modules are available in the firmware. For V1.22.1, it lists both network and urequests.

>>> 
MicroPython v1.22.1 on 2024-01-05; Raspberry Pi Pico W with RP2040
Type "help()" for more information.
>>> help("modules")
__main__          array             framebuf          random
_asyncio          asyncio/__init__  gc                re
_boot             asyncio/core      hashlib           requests/__init__
_boot_fat         asyncio/event     heapq             rp2
_onewire          asyncio/funcs     io                select
_rp2              asyncio/lock      json              socket
_thread           asyncio/stream    lwip              ssl
_webrepl          binascii          machine           struct
aioble/__init__   bluetooth         math              sys
aioble/central    builtins          micropython       time
aioble/client     cmath             mip/__init__      uasyncio
aioble/core       collections       neopixel          uctypes
aioble/device     cryptolib         network           urequests
aioble/l2cap      deflate           ntptime           webrepl
aioble/peripheral dht               onewire           webrepl_setup
aioble/security   ds18x20           os                websocket
aioble/server     errno             platform
Plus any modules on the filesystem
>>> 

[opiedopy]

Rob, Thank you for the comments and question. No, I only use Thonny. Code works fine with v1.20.0 Micropython firmware on Pico W 1 but not with v1.22.1 firmware on Pico W 1. I will try to be more informative later this morning. Opie

…

On Sun, Jan 21, 2024 at 3:18 AM Robert Hammelrath ***@***.***> wrote: Your observations seems a little bit inconsistent. network is a built-in module of the firmware. You would usually not load it, it's simply there. The urequests module is as well by default included into the firmware. Also, there is no need to import both time and utime. utime is an alias of time and is kept for legacy. So it may be that the hiccups you see are caused by Thonny. Do you have the same problems when not using Thonny? — Reply to this email directly, view it on GitHub <#13488 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASEPKVA6IZEOWWBQZJ6CPD3YPTFOTAVCNFSM6AAAAABCDTGKISVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DCOJWGI2TE> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[opiedopy]

Robert-hh,
Thanks. Yes, there are inconsistancies. I will try to add info below:

First, I unloaded the 2023 version uf2 from my Pico W and re-loaded the 2024 version uf2 bootloader. I ran the code on Thonny. I did not have any module issues this time since I fixed those problems by adding modules and now there are no missing modules flagged by Thonny.

Second, I ran the 'help modules" command with both 2023 and 2024 versions of uf2. There are some differences between the modules and I include the outputs in my next reply in order to keep this reply shorter.

Third, I include the temperature outputs that are verified correct with 2023 uf2 version of bootloader but incoorect with 2024 version of bootloader. This is my MYSTERY.......

Fourth, I include my code.

Fifth, you may notice that I prefer to use ntc 10k thermistors and therefore use the Steinhart equation to linearize the ntc readings.

Sixth, I send my data to ThingSpeak so as to be able to see data on the internet.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
::::::::::::::::::::::::
using April 2023 bootloader RPI_PICO_W-20230426-v1.20.0.uf2 on Pico W 1
(note: I have several Pico W boards and I want to keep them straight so I have added id "1" to this board on edit.)

code output on Thonny:

Connected.
network config: ('192.168.1.30', '255.255.255.0', '192.168.1.1', '192.168.1.1')
Getting data to send
Temperature Pico: 68.88269
Temperature spare: 54.69748
Temperature SPA: 56.87062

note 1: it continues like this forever, without fail, every 30 to 40 seconds
note 2: Pico W sitting on my desk in my <cold> office.....Jan 21 2023 717am
        SPA thermistor slightly closer to laptop.  
        Temperatures verified by infrared device.
note 3: connection immediate !

using Jan 2024 bootloader RPI_PICO-20240105-v1.22.1.uf2 on Pico W 1.

code output on Thonny:

>>> 
>>> %Run -c $EDITOR_CONTENT
connecting to network...
-------- eight more connecting messages truncated by me here
connecting to network...
network config: ('0.0.0.0', '255.255.255.0', '192.168.0.1', '8.8.8.8')
Getting data to send
Temperature Pico: 73.93864      << note by me: unverifiable by me
Temperature spare: 72.95879     <<note by me: actual temp is 54 !
Temperature SPA: 73.35374       << note by me: actual temp is 56 !
 waiting for wifi to come back.....
 waiting for wifi to come back.....
 ------60 more waiting messages truncated by me here
 waiting for wifi to come back.....
Rebooting
PROBLEM IN THONNY'S BACK-END: Exception while handling 'Run' (ConnectionError: device reports readiness to read but returned no data (device disconnected or multiple access on port?)).
See Thonny's backend.log for more info.
You may need to press "Stop/Restart" or hard-reset your MicroPython device and try again.

Process ended with exit code 1.

note 1: wrong temperatures (see above)
note 2: many tries to connect, program wifi lost afterwards...

Conclusion: I am not able to use the January Micropython bootloader version with my Pico W. Not sure why.

[robert-hh]

Please enclose code in lines with three backticks ```, that will preserve the code structure. You can edit your previous post.

[opiedopy]

My modules:

using Jan 2024 bootloader, results of Thonny >>>help("modules")

__main__          array             framebuf          random
_asyncio          asyncio/__init__  gc                re
_boot             asyncio/core      hashlib           requests/__init__
_boot_fat         asyncio/event     heapq             rp2
_onewire          asyncio/funcs     io                select
_rp2              asyncio/lock      json              socket
_thread           asyncio/stream    lwip              ssl
_webrepl          binascii          machine           struct
aioble/__init__   bluetooth         math              sys
aioble/central    builtins          micropython       time
aioble/client     cmath             mip/__init__      uasyncio
aioble/core       collections       neopixel          uctypes
aioble/device     cryptolib         network           urequests
aioble/l2cap      deflate           ntptime           webrepl
aioble/peripheral dht               onewire           webrepl_setup
aioble/security   ds18x20           os                websocket
aioble/server     errno             platform

using April 2023 bootloader, results of Thonny >>>help("modules")

__main__          lwip              uasyncio/lock     ure
_boot             math              uasyncio/stream   urequests
_boot_fat         micropython       ubinascii         uselect
_onewire          mip/__init__      ucollections      usocket
_rp2              neopixel          ucryptolib        ussl
_thread           network           uctypes           ustruct
_uasyncio         ntptime           uerrno            usys
_webrepl          onewire           uhashlib          utime
builtins          rp2               uheapq            uwebsocket
cmath             uarray            uio               uzlib
dht               uasyncio/__init__ ujson             webrepl
ds18x20           uasyncio/core     umachine          webrepl_setup
framebuf          uasyncio/event    uos
gc                uasyncio/funcs    urandom

[robert-hh]

What should be considered first is the inability to connect WiFi.
The temperature reading is then next. You mentioned that you use an NTC for temperature reading. I assume that it is in a kind of voltage divider. What is the reference voltage for this divider? Is it a stable voltage designed as reference voltage or the 3.3V supply?

[opiedopy]

I use the 3.3v marked "out" . Pin # 36 on Pico W

[opiedopy]

Whoops. On edit, I deleted my previous post bc it had passwords. I'll try again.

# Program by Shore to measure two temperatures SPA and spare
# on a Raspberry Pi Pico W, and write the data to the IoT cloud ThingSpeak
# and display it there.  Thanks to hippy from Raspberry Pi Forum for program help.
#     Mathworks info
#     https://thingspeak.com/channel/2392138
#        
#        Channel ID: 2392138
#        Author: ShoreNice
#        Access: Public

import machine
import urequests 
from machine import Pin,Timer
import network, time
import utime
import math

####
thermistor28 = machine.ADC(28)  #hwr, hot water return, 10K NTC thermistor typical
thermistor27 = machine.ADC(27)  #hws, hot water supply temperature
sensor_temp = machine.ADC(4) #internal gpio29, internal temperature of Pico W
conversion_factor = 3.3 / (65535) # for internal temperature of Pico W

#######


#######
led = Pin("LED", Pin.OUT)  #pico w led flasher
tim = Timer()
HTTP_HEADERS = {'Content-Type': 'application/json'} 
THINGSPEAK_WRITE_API_KEY = '0MMB6secretPFNNLL698'  
 
ssid = 'ssid secret'  
password = 'secret'


# Configure Pico W as Station
sta_if=network.WLAN(network.STA_IF)
sta_if.active(True)
 
for _ in range(10):
        print('connecting to network...') 
        sta_if.connect(ssid, password)
        time.sleep(1)
        if sta_if.isconnected():
            print('Connected.')
            break
        time.sleep(11)
 
print('network config:', sta_if.ifconfig()) 
def tick(timer):
    global led
    led.toggle()

tim.init(freq=1, mode=Timer.PERIODIC, callback=tick)

while True:
    print("Getting data to send")
    time.sleep(11)
    ##### spa
    temperature28_value = thermistor28.read_u16()
    Vr28 = 3.3 * float(temperature28_value) / 65535
    Rt28 = 10600 * Vr28 / (3.3 - Vr28)
    temp28 = 1/(((math.log(Rt28 / 10000)) / 3950) + (1 / (273.15+25)))
    Cel28 = temp28 - 273.15
    Fah28 = Cel28 * 1.8 + 32 + 2.0
    #print ('Celsius: %.2f C  Fahrenheit: %.2f F' % (Cel28, Fah28))
    utime.sleep_ms(200)
    
    ##### spare
    temperature27_value = thermistor27.read_u16()
    Vr27 = 3.3 * float(temperature27_value) / 65535
    Rt27 = 9925 * Vr27 / (3.3 - Vr27)
    temp27 = 1/(((math.log(Rt27 / 10000)) / 3950) + (1 / (273.15+25)))
    Cel27 = temp27 - 273.15
    Fah27 = Cel27 * 1.8 + 32
    #print ('Celsius: %.2f C  Fahrenheit: %.2f F' % (Cel27, Fah27))
    utime.sleep_ms(200)
    
    ##### PICO W TEMP
   
    reading = sensor_temp.read_u16() * conversion_factor
    temperature = (27 - (reading - 0.706)/0.001721)
    fahrenheit = ((temperature*(9/5))+32)
    #print(fahrenheit)
    utime.sleep(2)
   
    time.sleep(5)
    
    t2 = (Fah27) #HWS
    t3 = (Fah28) #HWR
    #####
    t  = (fahrenheit) #PICO TEMP
    
    print("Temperature Pico: {}".format(fahrenheit))
    print("Temperature spare: {}".format(Fah27))
    print("Temperature SPA: {}".format(Fah28))
    
    readings = {'field1':t, 'field2':t2, 'field3':t3}
    
    for retries in range(60):     # 60 second reboot timeout
        if sta_if.isconnected():
            print("Connected, sending")
            try:
                request = urequests.post( 'http://api.thingspeak.com/update?api_key=' + THINGSPEAK_WRITE_API_KEY, json = readings, headers = HTTP_HEADERS )  
                request.close()
                time.sleep(20)
                print("Write Data to ThingSpeak ",readings)
                print(" Successful  ")
                break
            except:
                print("Send failed")
                time.sleep(1) 
        else:
                print(" waiting for wifi to come back.....")
                time.sleep(1)
    else:
        print("Rebooting")
        time.sleep(1)
        machine.reset()   
print("Sent, waiting awhile")
time.sleep(10) 

[robert-hh]

One comment about the way you connect to WiFi: The connect statement is required only once. Like

# Configure Pico W as Station
sta_if=network.WLAN(network.STA_IF)
sta_if.active(True)
print('connecting to network...') 
sta_if.connect(ssid, password)
 
for _ in range(10):
    if sta_if.isconnected():
        print('Connected.')
        break
    time.sleep(11)

[opiedopy]

Robert-hh

I put the v1.20.0 firmware back in so you can see the ThingSpeak with correct temperature readings, verified with infrared and ice bath etc. You are welcome to edit link to make it url. My laptop seems to fail to use above shortcuts. And notice that this will continue, connected by wifi all day long, etc etc without disconnecting

https://thingspeak.com/channels/2392138
on Pico W 1.

[robert-hh]

Please have WiFi working first, then look at the difference of measurement. The 3.3V of the Pico W will be slightly different whether WiFi is working or not. That will affect your temperature readings.

About the ADC a note in the Pico Datasheet:
For much improved ADC performance, an external 3.0V shunt reference, such as LM4040, can be connected from the
ADC_VREF pin to ground. Note that if doing this the ADC range is limited to 0-3.0V signals (rather than 0-3.3V), and the
shunt reference will draw continuous current through the 200R filter resistor (3.3V-3.0V)/200 = ~1.5mA.

[opiedopy]

You are certainly knowledgeable. I did verify up and down the range and my two sensors are very accurate as wired if I use the Micropython firmware version v1.20.0 in the Pico W. I wire the GPIO input to the junction of thermistor and 10k divider resistor. Then the other leg of thermistor goes to ground and the other leg of 10k resistor goes to 3.3 v out. I calibrate on other projects by adjusting the 10k resistor amount to exact VOM reading, and then add an offset if needed for final number.

However, I will vote to accept your answer because you bring up a LM4040 suggestion that, while I won't do it, may be something that version v1.22.1 requires? Or maybe, the v1.22.1 version reacts with math modules do the log differently and require the LM4040. As I said, I will continue to use only the firmware version v1.20.0 since it works excellently for me. But your noble effort to help me solve the v1.22.1 issues may not go to waste if something similar pops up for another person out there.

Thanks!
solved.....for sensor, and maybe solved for wifi? Wifi module may act differently with v1.22.1 firmware and my code?
NO - on edit, I removed this as the answer. Robert-hh encouraged me to be systematic and I did, resulting in new info below.

[robert-hh]

The WiFi connect code should have been different with the 4/2023 version as well. Calling sta_if.connect() is a problem that showed up frequently.
Does WiFi work again with the firmware v1.22.1, when you pull sta_if.connect() out of the waiting loop? It should. I use the same structure myself and it follows the example in the documentation, e.g. here https://docs.micropython.org/en/latest/esp32/quickref.html#wlan. That example should better be in the generic WLAN section.

[opiedopy]

i will try your suggestions below. Thanks

[opiedopy]

I have two spare Pico Ws. (On edit, I have labeled these 1 and 2) I will put firmware v1.20.0 in Pico W 1 and firmware version v1.22.1 version in Pico W 2 and then change code in both according to your instructions, but maybe in a day or two. Thanks again …..,.,

…

On Sun, Jan 21, 2024 at 11:15 AM Robert Hammelrath ***@***.***> wrote: The WiFi connect code should have been different with the 4/2023 version as well. Calling sta_if.connect() is a problem that showed up frequently. Does WiFi work again with the firmware v1.22.1, when you pull sta_if.connect() out of the waiting loop? It should. I use the same structure myself and it follows the example in the documentation, e.g. here https://docs.micropython.org/en/latest/esp32/quickref.html#wlan. That example should better be in the generic WLAN section. — Reply to this email directly, view it on GitHub <#13488 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASEPKVHS6LTJTYBUGIOG4C3YPU5KNAVCNFSM6AAAAABCDTGKISVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DCOJZGYYTC> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[Josverl]

@opiedopy
Please use the standard terminology for firmware and version

Working firmware version : v1.20.0
RPI_PICO_W-20230426-v1.20.0.uf2

Non-working firmware version v1.22.1:
RPI_PICO_W-20240105-v1.22.1.uf2

A bootloader is a different piece of software altogether bootloaders and dates are confusing.

[opiedopy]

Josveri,
Thank you! I made the edits to correct terminology.

[opiedopy]

Aok. I’ll edit later tonight …..,.,,

…

On Sun, Jan 21, 2024 at 3:58 PM Jos Verlinde ***@***.***> wrote: @opiedopy <https://github.com/opiedopy> Please use the standard terminology for firmware and version Working *firmware* version : *v1.20.0* RPI_PICO_W-20230426-v1.20.0.uf2 Non-working *firmware* version *v1.22.1*: RPI_PICO_W-20240105-v1.22.1.uf2 A bootloader is a different piece of software altogether bootloaders and dates are confusing. — Reply to this email directly, view it on GitHub <#13488 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASEPKVDOBSR6PJWY6HWASTDYPV6QHAVCNFSM6AAAAABCDTGKISVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DEMBRG43TI> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[opiedopy]

OK-

I followed good suggestions and did evaluation and have the following conclusions.

I have two Pico W's, side by side on my desk. (On edit, now labeled 1 and 2)

Pico W 1 has working firmware v1.20,0 and Pico W 2 has Non-Working Firmware v1.22.1
The software is identical in each Pico W except for different firmware and also code sending results to two ThingSpeak channel web services for viewing over the web.

First, the wifi works with both Pico W 1 with v1.20.0 and Pico W 2 with v1.22.1 firmware. That is good because my code is copied directly from the forum member, "hippy" over at the main Raspberry Pi main. Thanks, hippy. Reinstalling everything carefully and several reboots knocked it into working well with both firmwares on both Pico W's. It has been over three hours of continuous wifi connection on both Pico W's..
Therefore, robert-hh, I will not be making the wifi code changes you recommended because wifi is stable now.

Second, my original thread title is confirmed. My sensors work under firmware v1.20.0 but do not work accurately with firmware v1.22.1. They read over 20 degrees too high with v1.22.1 And I believe it is fair to say that it is not a voltage reference issue that robert-hh asked about. I conclude that because not only are my thermistors inaccurate with v1.22.1, but also the internal Pico W board sensor readings are different as well.

(On edit - ignore next statement. I believe that an infrared measurement of the internal board sensor may be impossible to be accurate, so ignore my conclusion, except to say the Pico W 1 and Pico W 2 internal sensor temps are not the same, but that may be caused by inherent differences in manufacture?)

**** ignore ---- My infrared gun sensor measures 74 degrees internal board sensor with laser sighting on v1.20.0 and 74 with v1.22.1 but as the results show below, the v1.22.1 measures 10 degrees higher. ****Ignore

The following data support my conclusions?:

Data Item # 1
non-working firmware with Pico W 2
inaccurate
v.22.1 result: Sensor values in error by test instruments
from Thonny run:

>>> %Run -c $EDITOR_CONTENT
connecting to network...
Connected.
network config: ('192.168.1.115', '255.255.255.0', '192.168.1.1', '192.168.1.1')
Getting data to send
Temperature Pico: 84.79182
Temperature SPA: 89.57056
Temperature SPARE: 80.98407
Connected, sending
Write Data to ThingSpeak  {'field2': 89.57056, 'field1': 90.79182, 'field3': 80.98407}
 Successful  

Anyone can view my public data for the non-working firmware v1.22.1 on Pico W 2 at
https://thingspeak.com/channels/2278931
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
working firmware with Pico W 1

v.20.0 result: Sensor values confirmed by test instruments
from Thonny run:

>>> %Run -c $EDITOR_CONTENT
connecting to network...
Connected.
network config: ('192.168.1.30', '255.255.255.0', '192.168.1.1', '192.168.1.1')
Getting data to send
Temperature Pico: 74.83726
Temperature SPA: 66.42764
Temperature SPARE: 62.38741
Connected, sending
Write Data to ThingSpeak  {'field2': 66.42764, 'field1': 79.83726, 'field3': 62.38741}
Successful  

on edit: ----
I removed this link from service because the issue has been resolved.....
Anyone can view my public data for the working firmware v1.20.0 on Pico W 1 at:
h ttps : // thingspeak.com/channels/2no-longer-available-2138

[robert-hh]

So it's good that WiFi works now for both firmware versions. It is however interesting that you get different ADC readings between the two firmware versions. In order to isolate the issue, I made a simple test set-up with applying an external Voltage to ADC0 and reading the result under varying conditions. The external voltage is 1.51V. I soldered a 10nF capacitor close to the ADC input to lower the reading impedance, and since the ADC readings were still noisy, the test code takes an average of 1000 samples taken within 10 seconds. The test runs were repeated several times to see fluctuations. Results:

v1.20.0:
Input voltage 1.51 V
without WiFi: 29830 +/- 2
with Wifi: 29884 +/- 2

v1.22.1
Input voltage 1.51 V
without WiFi: 29803 +/- 2
with Wifi: 29830 +/- 2

Voltage at ADC_Vref: 3.29V under all conditions, when ADC is enabled..
Measuring the voltage at the ADC0 pin with a multimeter returns 1.507 V. With the multimeter applied, the ADC reading was 29835 +/- 10, compared to an expected value of 29919 (1.507 / 3.29 * 65536). Note: The output impedance of the Voltage source is 50Ohm. Adding a Multimeter with 10MOhm should not drop the voltage by that amount. So other effects happen.

The results are somewhat different. Using an NTC, a lower reading from the ADC result in higher temperature readings. I do not know the input voltage at your set-up, and the transfer ratio between input voltage variations to output value differences.

Note that the ADC is quite noisy. Proper input filtering should be done.

[robert-hh]

Repeating the same test with a fresh alkaline AA battery as voltage source soldered with short wires to the RPI W gives different results.

Battery voltage: 1.602V, VRef 3.29V, expected value 31911

v1.20.0:
Input voltage 1.602 V
without WiFi: 31660 +/- 2
with Wifi: 31758 +/- 2

v1.22.1
Input voltage 1.602 V
without WiFi: 31658 +/- 2
with Wifi: 31758 +/- 2

So the differences disappeared using a different voltage source. None of them meet the expected value. The difference to the previous test is the impedance of the voltage source and the wire length..

[robert-hh]

Repeating the same test with 1k resistor between battery and ADC returns:

Voltage at ADC input: 1.549V, raw battery voltage 1.602V

v1.20.0:
Input voltage 1.549 V
without WiFi: 30586 +/- 2
with Wifi: 30694 +/- 2

v1.22.1
Input voltage 1.549 V
without WiFi: 30585 +/- 2
with Wifi: 30690 +/- 2

The expected value is at 1.549V ADC input and 3.29 V Vref is 30885, which is not met with any firmware version.
The voltage drop over the 1k resistor indicates an ADC input resistnace of ~30k.

[mendenm]

Remember the ADC error curve in the manual for the RP2040. The ADC is effectively only 8 bits, because of the large linearity errors. If you are operating near any one of the big jumps in the response, you will get erratic results. The ADC in the current tranche of RP2040s had a mis-calculated capacitance, resulting in really awful performance. Added note: This is documented in figure 116 on page 565 of the data sheet.

[opiedopy]

Since I have the ability to evaluate data using ThingSpeak, I offer some screenshots that may further illustrate the different adc results for Pico W 1 ( the "1" is my designation to keep boards identified) with v1.20.0 version firmware
and for Pico W 2, with v1.22.1 version firmware.

At 730 est this morning I put plastic over both boards and also the spa sensor. Then I laid a package of frozen vegetables on both boards, 1 and 2, in order to cool them temporarily.

ThingSpeak maintains all data for over a year. And charting is available.

Here are results, again showing the faulty adc conclusion for Pico W 2 using firmware version v1.22.1

Results: Pico W 1 with working firmware v1.20.0 gave temperatures for spa sensor and internal temperature of 35 deg F and 54 deg F respectively. (Using infrared measurement, the 35 deg F was accurate.)

Pico W 2 with non-working firmware v1.22.1 gave temperatures for spa sensor and internal temperature of 58 deg F and 62 deg F respectively. (Using infrared measurement the 58 deg F was 23 degrees too high.)

I know of no way to independently measure the internal temperature of the board with an instrument, but v1.22.1 firmware shows internal temperature 8 degrees higher than V1.20.0 under similar circumstances. Does this add to the confusion?

[robert-hh]

Do you use different Pico W devices for the test and different sets of sensors, or the same device with the same sensors, but different firmware?

Edit: I checked the source code of both MicroPython and the RPi library, and there are no changes to ADC since Januar 2023 which could explain your observation.

[opiedopy]

Yes. I have a Pico W that I label as "1" with two ntc thermistors and also I have a separate Pico W "2" with two separate sensors. Pico W "1" has v1.20.1 firmware and Pico W "2" has v1.22.1 firmware. I call v1.22.1 firmware "non-working" but that is yet to be verified by others. I certainly could be wrong about something..... I am happy to use the accurate (for me) v1.20.1 in the future but also happy to help solve this mystery...

In that light, I have a third Pico W, unopened, from vendor a month or two ago. If asked to, I would be willing to make a third setup with new thermistors and report back here. Let me know if that would help, and which version I should put in it,.

[robert-hh]

What I would do is run swap tests, unless you did that already:

• with the existing sensor configuration, run v1.22.1 on Pico "1"
• swap the sensors between Pico "1" and Pico "2" w/o changing the firmware assignments

Edit: It the wiring of the sensors exactly the same in both cases?

[opiedopy]

Ok.

The simplest exercise first, I swapped the two sensors from Pico W "1" with Pico W "2"
Note: I moved sensors a bit during process so there may be minor changes.
As before, Pico W "1" are the actual, accurate readings in my office as I type this. Pico W "2" are not accurate.

Results below:

Pico W "2" before sensor swap:

Pico W "2" after swapped sensors:

Pico W "1" before sensor swap:

Pico W "1" after swapped sensors:

[robert-hh]

So it looks like the sensors are fine.

[opiedopy]

Now for the version swap as you asked for ----- ".....with the existing sensor configuration, run v1.22.1 on Pico "1": "

I installed on Pico W "1" what I thought was v1.22.1 but I was confused when I found these two files in my Downloads:

RPI_PICO_W-20240105-v1.22.1.uf2
RPI_PICO-20240105-v1.22.1.uf2

Hmmm. I know that the first one is the one I want, but I decided to try the second one first. Eureka! moment because using the second one caused me to be missing network, urequests and socket module packages. That must have been what happened when I included module issues in my thread way above before my module issues disappeared. Well, now I realize, that the module problems went away during my 10 hours of struggle only because I bumbled into loading the correct Pico W specific v1.22.1. I wonder how many folks may have made that same mistake?

So, with the correct v1.22.1 firmware here are the results:

>>> %Run -c $EDITOR_CONTENT
connecting to network...
connecting to network...
Connected.>>> %Run -c $EDITOR_CONTENT
connecting to network...
connecting to network...
Connected.
network config: ('192.168.1.30', '255.255.255.0', '192.168.1.1', '192.168.1.1')
Getting data to send
Temperature Pico: 73.09599
Temperature SPA: 77.76223
Temperature SPARE: 76.39398
Connected, sending
Write Data to ThingSpeak  {'field2': 77.76223, 'field1': 73.09599, 'field3': 76.39398}
 Successful  

So, these readings are inaccurate...........with the test of v1.22.1 (W version) onto Pico W "1"

[opiedopy]

robert-hh,
I put Pico W "1" back with working firmware v1.20.0 after above test.

May I suggest that we eliminate the thermistor part of the issue? If you send me a simple voltage divider circuit design using a known, fixed resistor(s) ohm value, and send me the code you want me to use, I will modify Pico W "2" that has v1.22.1 firmare and install the code for a test to see if I can achieve your calculated predicted values?

[opiedopy]

Here is the screenshot of Pico W "1" with v1.20.0 to the left, then a drop while I swapped sensors, then normal, then a jump up to inaccurate temperatures when I went to v1.22.1, then drop back down to accurate with v1.20.1 And the inaccuracy is not a simple offset, it goes more inaccurate as temperatures change.

[robert-hh]

May I suggest that we eliminate the thermistor part of the issue? If you send me a simple voltage divider circuit design using a known, fixed resistor(s) ohm value, and send me the code you want me to use, I will modify Pico W "2" that has v1.22.1 firmware and install the code for a test to see if I can achieve your calculated predicted values?

Since you use 10k NTCs, I have set up a 2:1 voltage divider between VrefADC and GND of 10k resistors with the middle junction to ADC0, and a 10nF capacitor between A0 and GND. All leads as short as possible, The test code is below. I see no substantial change between v1.20 and v1.22. But the whole set-up shows a substantial temperature drift. This drift is as well visible at the ADC0 input voltage. The VRefADC does not change with the temperature.
Readings:
Input voltage at ADC0.

• when settled after a while: 1.378 V (varies slightly with the WiFi load)
• when cooled down: 1.332V

ADC readings:

• when settled: 27600 - 27620 (varies with the WiFi load)
• when cooled down: 26727

This is the same for both v1.20.0 and 1.22.1. The ration between cooled and warm readings is the same for ADC0 input voltage and ADC readings. So the effect may be cause by the input circuitry of the Pin.

from machine import ADC
import time

adc = ADC(0)
def run(n=100):
    sum = 0
    for _ in range(n):
        sum += adc.read_u16()
        time.sleep_ms(10)
    print(sum // n)

run()

Here is the set-up at a breadboard:

P.S.: I do not use Thonny, but mpremote and picocom.

[mendenm]

With 10k resistors, one should expect quite a bit of drift due to leakage currents in the ADC input. Table 626 in the RP2040 spec sheet says the input impedance is 100k, and the two 10k in parallel as a divider have 5k effective impedance, which will make it very sensitive to changes in the input resistance. Mostly, people trying to really do serious a/d on systems of this nature keep the impedance down below 1k, and best at below 100 ohms, using a buffer amplifier.

[robert-hh]

I know. For my other test above with the battery the input impedance was low. But here I use a similar set-up as the initial poster.
Besides that, if the ADC values matter, I would use an external ADC like the ADS1115.

b.t.w. It seems that the input impedance of the PICO is more in the range of 25k-30k, not 100k, given the difference between 1.378V and 3.27V/2 and 5 k source impedance.

[mendenm]

Certainly with the a/d on this tranche of rp2040s, you really want an external! Although I am using it for AC small-signal work, by biasing it to 25%, and only using 25% of its total range. It then isn't a bad 10-bit a/d.

[opiedopy]

. . .
robert-hh
there may be a typo here, I think the "10" should read "the" in the sentence with .."of 10 resistors with .."
. . .

I breadboarded your design with a brand new Pico W "3". When running the code, it gave a single value each click. I put your code in a 15 x loop to get more readings on each click.

Here are results:
For Pico W "3" with v1.22.1:

>>> %Run -c $EDITOR_CONTENT
Calculated sum of v1.22.1 =  32147
Calculated sum of v1.22.1 =  32142
Calculated sum of v1.22.1 =  32145
Calculated sum of v1.22.1 =  32139
Calculated sum of v1.22.1 =  32143
Calculated sum of v1.22.1 =  32142
Calculated sum of v1.22.1 =  32139
Calculated sum of v1.22.1 =  32143
Calculated sum of v1.22.1 =  32143
Calculated sum of v1.22.1 =  32145
Calculated sum of v1.22.1 =  32144
Calculated sum of v1.22.1 =  32139
Calculated sum of v1.22.1 =  32142
Calculated sum of v1.22.1 =  32142
Calculated sum of v1.22.1 =  32144

average for 15 above readings for v1.22.1 = 32142.6000
. . . ./ . . . . . . . . . .

and for Pico W "3" with v1.20.0

>>> %Run -c $EDITOR_CONTENT
Calculated sum of v1.20.0 =  32135
Calculated sum of v1.20.0 =  32139
Calculated sum of v1.20.0 =  32140
Calculated sum of v1.20.0 =  32137
Calculated sum of v1.20.0 =  32136
Calculated sum of v1.20.0 =  32140
Calculated sum of v1.20.0 =  32133
Calculated sum of v1.20.0 =  32141
Calculated sum of v1.20.0 =  32135
Calculated sum of v1.20.0 =  32137
Calculated sum of v1.20.0 =  32137
Calculated sum of v1.20.0 =  32134
Calculated sum of v1.20.0 =  32140
Calculated sum of v1.20.0 =  32136
Calculated sum of v1.20.0 =  32136
>>> 

average of above v1.20.0 = 32137.06667

on edit, schematic picture had typo, I could not update it here, so I re-sent it below.....

[mendenm]

@robert-hh I did notice that the apparent error looked large for even the nominal 100k input impedance. I have not dug into the source to make sure that setting a pin to an ADC input is correctly disabling the digital input buffers. If you know the source well, can you take a look to make sure that the correct bit is getting set on the pad when the pin as assigned to an ADC?

Update: I looked at the code. It appears to call the correct pico-sdk library function to put the pin in the appropriate high-Z state. I'm not sure why the input seems pulled as much as it is. I may have to experiment a bit with this.

[opiedopy]

I thought of something else to check. At what point did the "different result sensor" phenomenon occur in the builds? I went back and put in all the firmware and tried them all. Here is what I found:
At the time I am testing this now, it is about 63 degrees in my office. v1.21.1 (different result) build produces about 78 deg F indicated for my sensors. v1.20.0 (working result) build give me the correct temperature of 63 deg F,

Working builds:
v1.21.0 (2023-10-05) .uf2 / [Release notes]
v1.20.0 (2023-04-26) .uf2 / [Release notes]

Different Result Builds:
v1.22.1 (2024-01-05) .uf2 / [Release notes] (latest)
v1.22.0 (2023-12-27) .uf2 / [Release notes]

plus all the preview builds........

on edit - I took out the word "faulty" builds in this comment. I apologize to all the hard working folks who make all this happen. I should have used another word. If moderator wishes, I could re-edit that word out.... In fact, it may be a coincidence? By that, I wonder if after October of 2023, could a supporting module (like math?) have changed when I did my usual apt upgrade, etc? And the supporting module causes my errors and not the firmware upgrade build? Just asking...

[robert-hh]

About going back in history: there is usually almost not difference (if at all) between the last preview build of a version and the next version. So one had to get back into all the intermediate steps to find the place where something has changed. That s done sometimes, and does not take too long. You would do a binary search. But it requires to build the firmware yourself.

[robert-hh]

@opiedopy The sample code I provided runs ADC 100 times and returns the average. You can as well change it to larger numbers.

The diagram you sketched above looks wrong. I added the 10nF capacitor between ADC0 and GND. It reduces the impedance for the sample phase of the ADC and suppresses RF noise. I have a lot of that here from a nearby radio station.

Nevertheless, the results to v1.20.0 and 1.22.1 seem comparable, less than 1 digit of the internal ADC.

With the other board & set-up you see a difference. And your results with the voltage divider are different to mine, at least the raw readings. But maybe that's related to the batch of the PICO_W devices. The one I use is pretty old, maybe the first batch. Maybe I should get new ones. Anyhow there are differences in your initial set-up when using different firmware versions, reason unknown.

The libraries used for the firmware are not related to code on your PC. So any upgrade of it will not affect the calculations in the board.
About terminology: I would not have called it "faulty", just "different". But keep it as it is.

@mendenm Noticing the difference between the actual input impedance and the data sheet, I glance though the code and did not seen anything obvious. But I did not compare it bit-by-bit with the RP2040 data sheet. And the behavior is the same for v1.20.0 and v1.22.1. So for a firmware version difference it did not matter.

[mendenm]

@robert-hh Could you try measuring the readout with a 10k to Vref, then 10k to ground, then repeat with 100k to Vref and 100k to ground? That would provide a lot of info about the input behavior.

[robert-hh]

@mendenm I made my test above already with 10k resistors, as you can see in the picture. I do not expect much from using 100k, except a drop in the average input voltage. I should get new PICO-W devices instead to see, if there is a difference.

About buffering the input for ADC: In a different project I used MCP602 Op Amps. Voltage range 2.7-6V, rail-to-rail operation, simple application. But I used an ADS1115 as well as ADC. But it was a ESP8266 project, where the ADC is even worse.

[opiedopy]

my added loop to your code:

    ############### robert
adc = ADC(0)
for n in range (15):
    def run(n=100):
        sum = 0
        for _ in range(n):
            sum += adc.read_u16()
            time.sleep_ms(10)
        print("Calculated sum of v1.20.0 = ",sum // n)
   
    run()
#######################

[robert-hh]

@mendenm Nevertheless I ran a test with the 100k resistors. No real difference between v1.20.0 and v1.22.1. Temperature sensitivity is the same. Interestingly the static voltage at ADC0 is about 0.5V, which is way less than expected. VRefADC is still 3.29 V.

[opiedopy]

previous picture had line error in drawing, here is my copy of robert-hh design as installed

ps: On edit, I confess that I previously did not use AGND as shown but used another GND. Subsequently, as part of my investigation I re-did the soldering and used AGND as shown above.

[opiedopy]

This morning I ran the two different firmwares and results are below. The two results are very similar. This leads me to think that the "difference" in my original topic thermistor outcomes (with different firm wares) is module-related somewhere in the version codes. I mean that v1.20.0 treats some module (math?) differently than v1.22.1. ??

>>> import sys
print(sys.version)
3.4.0; MicroPython v1.20.0 on 2023-04-26
>>> 
>>> %Run -c $EDITOR_CONTENT
Calculated sum of v1.20.0 =  32103
Calculated sum of v1.20.0 =  32108
Calculated sum of v1.20.0 =  32104
Calculated sum of v1.20.0 =  32107
Calculated sum of v1.20.0 =  32104
Calculated sum of v1.20.0 =  32103
Calculated sum of v1.20.0 =  32098
Calculated sum of v1.20.0 =  32102
Calculated sum of v1.20.0 =  32098
Calculated sum of v1.20.0 =  32105
Calculated sum of v1.20.0 =  32106
Calculated sum of v1.20.0 =  32106
Calculated sum of v1.20.0 =  32106
Calculated sum of v1.20.0 =  32108
Calculated sum of v1.20.0 =  32101
		average   =  32090
>>>



changed

>>> import sys
print(sys.version)
3.4.0; MicroPython v1.22.1 on 2024-01-05
>>> 
>>> %Run -c $EDITOR_CONTENT
Calculated sum of v1.22.1 =  32091
Calculated sum of v1.22.1 =  32089
Calculated sum of v1.22.1 =  32091
Calculated sum of v1.22.1 =  32091
Calculated sum of v1.22.1 =  32091
Calculated sum of v1.22.1 =  32091
Calculated sum of v1.22.1 =  32094
Calculated sum of v1.22.1 =  32090
Calculated sum of v1.22.1 =  32089
Calculated sum of v1.22.1 =  32086
Calculated sum of v1.22.1 =  32094
Calculated sum of v1.22.1 =  32094
Calculated sum of v1.22.1 =  32090
Calculated sum of v1.22.1 =  32089
Calculated sum of v1.22.1 =  32087
		average   =  32104
>>> 

```

[opiedopy]

But, the difference is not linear or steady offset. For example, at this time all sensors are under some frozen vegetables and v1.20.0 produces 40 degrees and the v1.22.1 produces 69 degrees.

[mendenm]

@opiedopy Neither of these numbers seems even vaguely correct for having the sensor under frozen vegetables. Somehow I think something is really wrong in both cases for your setup. Incidentally, why do you have an extra +2.0 in your conversion to Fahrenheit?

Also, why are you using 10600 for your reference resistance? Most nominal 10k thermistors are 10k at 25C. 10600 is typical of what they read at normal room temperature, close to 20C. Even cheap 10k thermistors are usually within 1% of nominal at 25C.

[mendenm]

@opiedopy I think I just may have found out your problem. You are create ADC(0), but ADCs may require a pin number, not an index. Can you try this whole thing with adc = ADC(Pin(26)) just to make sure you are initializing it correctly?

[robert-hh]

@opiedopy uses pin numbers in his initial code. And one can either use the channel number 0-3 or a gpio number 26 - 29

[mendenm]

@robert-hh @opiedopy OK, I missed that. I was looking at some of the code further down. I was wondering if there could be a bug in the rp2 implementation which didn't turn off the input buffers when the pin was addressed by index, instead of by pin numbers, resulting in a large bias current.

[opiedopy]

Again, explaining the "difference" with thermistors with v1.22.1 too high in temperature and not a linear offset.

import sys
print(sys.version)
3.4.0; MicroPython v1.22.1 on 2024-01-05
ht tps: // thingspeak.com/channels/2-no-longer-available-31

---

import sys
print(sys.version)
3.4.0; MicroPython v1.20.0 on 2023-04-26

https://thingspeak.com/channels/2392138

[opiedopy]

Marcus, Thank you for your comment. I have multiple checks on accuracy of readings for the v1.20.0 Pico board. The frozen vegetables were on top of a plastic bag to protect the two Picos. Additionally, my infrared reading was spot on and matched v1.20.0 Pico. I’ve used another Pico W in our Alaska property monitoring a 27 kw boiler for a year+. When I set boiler output for 160/140/120 adjustable I get Pico W info of exactly those readings that also confirm the dial gage on boiler. I reside in NC and depend on the Pico W reading from there via internet. I am in no distress, as I initially stated. I can use older builds forever I suppose. It is just a curious circumstance that Robert and you are helping figure out. I remain grateful. Perhaps the research will help others in future. ………..

…

On Tue, Jan 23, 2024 at 1:39 PM Marcus Mendenhall ***@***.***> wrote: @opiedopy <https://github.com/opiedopy> Neither of these numbers seems even vaguely correct for having the sensor under frozen vegetables. Somehow I think something is really wrong in both cases for your setup. — Reply to this email directly, view it on GitHub <#13488 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASEPKVBB3RHQZRNNWCUPLBTYP77WRAVCNFSM6AAAAABCDTGKISVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DEMRUGM4TK> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[robert-hh]

I does not seem to me that they merge. It looks more that the blue line has a time lag to the red line, and at a fast drop it then looks like a merge. And it's a slightly different decay rate for the falling temperature section.

[mendenm]

@opiedopy There is useful info in that plot. The 'merge' isn't interesting, though. You just had better thermal contact with the heat source when you did the orange run, so it cooled down faster, and crossed over the other curve on the way. The offset increases with decreasing temperature, which is increasing source impedance from the NTC. This is consistent with some extra current source pulling your input towards ground, since it appears from your equations that your thermistor is on the low side. At this point, I have no idea what it could be. My one Pico-W is tied up in an experiment, so I cannot try to replicate it here.

[opiedopy]

It's weird.......
on edit.... after mendenm's comment..... maybe not weird. I definitely was throwing conditions at the boards without a strict lab environment. The rough offset is visible though..

[opiedopy]

I am nearing the give up stage... ha

Tonight I tried some things. I read the specs on the Pico W ( https://datasheets.raspberrypi.com/picow/pico-w-datasheet.pdf )
I learned more about AGND. I did not use that pin (physical 33) but used another GND. So I resoldered my board to use AGND only. No effect on different outcomes.

I only use math.log and float in my code, so I did the voltage divider code of robert-hh and used those two terms in that code as a test, and no effect either.

So, for anyone reading all the above for the first time let me summarize.

I use Thonny IDE

1. I had a many month long successful Pico W setup in a remote house using two 10k ntc thermistors for temperature logging over wifi/internet.

2. I removed the Pico W to reprogram the ssid and password.

3. While on bench I decided to upgrade the firmware.

4. Upon repowering the Pico W had issues with modules and wifi and accuracy of readouts.

5. I discovered that I had made a mistake and used firmware for Pico instead of Pico W. There turns out to be a BIG difference.

6. Upon updating firmware correctly, the module and WiFi issues resolved themselves. But the sensor temperature was curiously too high by about 10 to 15 degrees F.

End of summary.

Working builds:
v1.21.0 (2023-10-05) .uf2 / [Release notes]
v1.20.0 (2023-04-26) .uf2 / [Release notes]

Different Result Builds:
v1.22.1 (2024-01-05) .uf2 / [Release notes] (latest)
v1.22.0 (2023-12-27) .uf2 / [Release notes]

I like thermistors for many reasons.

It may be we just wait to see if this comes up with anyone else, and re-visit the issue then. However, being retired gives me the time if anyone has an idea to try.

Cheers, and thank you very much.

Opie

[robert-hh]

I made another test. I do not know how the physical wiring of your sensor looks like. So I took the 10k resistor divider and added a longish wire (~9m on a coil, that's what I had in my workbench drawer) between the middle junction of the resistors and the ADC0 input. Then I tested it

a) just the wire -> 27480
b) with the 10nF capacitor immediately at ADC0 input ->27560
c) Since it is a twisted pair wire, putting the second wire to GND, w/o the cap: 27610.
With the cap at ADC0 it does not matter, whether the second wire is at GND or not.

So there are differences, but not between the firmware versions. With much longer wire the differences may be larger. So a test you could make is to add a cap at the Pico between the ADC input and GND.

Funny enough, the readings are lower than previously, and as well the DC input at ADC0. So there is something weird going on in the Pico. The leakage varies. I have to dive into GPIO settings by the pico-sdk.

[robert-hh]

I made an interesting observation. When the ADC pin is

• first set to Pin, input mode, and
• then configured as ADC

the input impedance is high (not like 25k), and the temperature dependency is gone. So you could try in your code to insert at the top before the line thermistor28 = machine.ADC(28) #hwr, hot water return, 10K NTC thermistor typical:

from machine import Pin
p27 = Pin(27, Pin.IN)   # the symbol names pxx do not matter. The can be omitted
p28 = Pin(28, Pin.IN)

Edit: It may not apply to your batch of the RP2040, since you had all the time reading with the resistor divider in the range of 32000.

[robert-hh]

On a second glance, the same can be achieved w/o calling Pin(27, Pin.IN) by calling e.g. thermistor28 = machine.ADC(Pin(28)). There is an omission in machine_adc.c, when the constructor ADC(x) is called with a number instead of a PIn object. Then, the pin will not be configured for ADC. Still it's not clear why there is a difference between firmware versions.

[mendenm]

@robert-hh @opiedopy That is exactly the sort of error I was sniffing for yesterday when I suggested trying to use the pin instead of the channel. I'm glad you found it! It was clear for a long time that the pin was in a low-impedance state and that the problem was likely related to that.

[robert-hh]

Still it's not clear why there is a difference between firmware versions.

[opiedopy]

Some post script thinking and observation:

I notice you did not instruct me to change the adc code for the internal sensor. I did not.

But this morning I decided to try both adc styles and run code:

Results below show no difference in internal Pico W sensor read out between coding:

adcpin = 4
sensor = machine.ADC(adcpin)
result:
Internal Sensor, deg F = 85.82

and

sensor = machine.ADC(4)
result:
Internal Sensor, deg F = 85.83

[robert-hh]

Obviously the two are the same, and it makes not difference if you supply the constant 4 or a symbol with 4 assigned to it. Both are integer objects.
For ADC, if you use a number between 0 and 4, it refers to ADC channel. You can use numbers between 26 and 29 or other ways to refer to a Pin, like Pin(26) ... or "GP26" as well. PIN 26 is connected to ADC channel 0, and so on. There is not Pin equivalent to Channel 4, the ADC for the internal temperature sensor, since that one is not connected to a Pin.
When using channel numbers like ADC(1) or Pin integers like ADC(27), the GPIO is not initialized, with the result we have seen and which requires to initialize the GPIO separately. When using ADC(Pin(27)) or ADC("GP27"), the GPIO is properly initialized.
That's not documented and partially inconsistent, since e.g. ADC(27) and ADC(Pin(27) and ADC("GP27") should behave consistently. Whether it is a reasonable approach to NOT initialize the GPIO when using the channel numbers 0 to 3 is a different topic.